On Friday 18 September 2009 11:23:17 Klaus Kaempf wrote:
> >
> > * /registration
>
> As Josef already mentioned, you might want to rename this to
> /registration/register. This way the url names the action ('register')
> and also matches Rails controller/action pattern for urls.Yes, it should be compatible with all other URLs. I discussed it with Schubi last week, and we decided to keep the URL short, as this action is the only one available. But I'm fine with renaming it to /registration/register > > POST > > run registration and return the/a result > > > > post data: > > > > <registration> > > <options> > > <debug>2</debug> > > <nooptional>1</nooptional> > > <nohwdata>1</nohwdata> > > This negation seems awkward. What's wrong with <optional> and <hwdata> ? > Boolean attributes should also get boolean values (i.e. 'true' instead > of '1'). Sure, only debug mode is non-boolean. Will change it. > But such details (type of attributes) are better left to ActiveResource. > > <forcereg>0</forcereg> This one is boolean, not part of the proxy and a needed switch. > > <httpproxy>http://my.proxy</httpproxy> > > <httpsproxy>http://my.proxy</httpsproxy> > > Hmm, the proxy should belong to the network settings. Yes this is correct, but for some reason we configured it manually in the current registration. I'll find out about if we really need this option. > > </options> > > > > <arguments> > > <argument> > > <name>key</name> > > <value>val</value> > > </argument> > > This also looks awkward (should be <key>value</key>) but thats > probably due to ActiveResource. No, its because the name of the keys are dynamic. There is no fixed list of possible keys. There can be any of them. > > ... > > </arguments> > > <registration> > > > > > > returns: > > > > <registration> > > <status>finished|missinginfo|error</status> > > <message>Some text to display</message> > > Where does this message come from, how is it translated ? The registration server can send translated messages if the language is supported by NCC (see as well "suse_register --locale=XY"). > Language setting should be a property of the frontend (webclient), the > service has no idea about the UI language. The target system has a default language. Thats the language the system gets registered with. And if a translation exists for this language the registration server sends answers in this language - these could be displayed. But if we want to keep the web-client's language setting separate from one on the target system then we need to have static texts and use exit codes to identify the actual status. > For the error results, use different class definitions all derived from a > common 'error' class. I guess discussing these classes is easier than > looking at raw xml. Missing information is not an error, but a valid status within the registration workflow - see my answer to Josef's eMail. > > There is only one action to perform the registration. And all data has to > > be send for each request, as it operates in stateless context. > > The following action depends on the answer to the request. If there are > > arguments missing a following call is needed (together with the > > additional arguments). > > Is there a state diagram available showing how requests and answers > relate ? I'll create one. Ciao, Daniel -- J. Daniel Schmidt <[email protected]> SUSE Linux Products GmbH Research & Development Maxfeldstr. 5 GF: Markus Rex, HRB 16746 (AG Nürnberg) D-90409 Nürnberg -- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
