On Friday 18 September 2009 01:50:57 josef reidinger wrote:

...

Registration Configuration: --------------------------------- * /registration/config GET get registration server

returns:

<registrationconfig> <server> <url>https://myregistration.server.com/center/regsvc</url> </server> </registrationconfig>

Hi, just few notes. Why get doesn't get certificate? Maybe someone find usefull to check server certificate

The idea is, to do all the certificate checking (and downloading the cert from a url) in the web-client and then the web-client PUTs the certificate itself to the target system. PUTting the certificate to the server only imports it to the certificates in /etc/ssl/certs. Ok, I could check for a fixed file name and dump it again - sure.

...

<!-- in case of missing arguments -->

I think that missing argument should be reported as error, also another controller handle it as error (I plan add specific exception for arguments missing/invalid). Do you have any reason to respond it as success response? Also status error is not good I think...thats reason why status code exist, just report problem in status code and explain problem in response. Don't mix success registration and problematic.

The design of the registration process is different to any other module that does configuration stuff. 1. A system does not know if it is registered or not You need to do a registration to find out. But after you registered you can not be sure, tthat the system is still registered - only the registration server knows, and by design you can not query for that status. 2. A system does not know what arguments (values) to ask from the user; it does not know if there might be something missing in the first place; you need to do a registration to find out, what arguments are needed for a registration. Thus the status "missing info" is a valid status within the workflow and not an error. Ciao, Daniel -- J. Daniel Schmidt SUSE Linux Products GmbH Research & Development Maxfeldstr. 5 GF: Markus Rex, HRB 16746 (AG Nürnberg) D-90409 Nürnberg -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

On Friday 18 September 2009 11:23:17 Klaus Kaempf wrote:

* J. Daniel Schmidt [Sep 17. 2009 22:14]:

...

Run Registration: ---------------------------------

* /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.

Well Daniel is correct that a REST API should be a name and not a verb, because a POST should "create a registration" and not "register", so the right thing would be to post to /somenamespace/registrations. Or? Duncan -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

On Monday 21 September 2009 09:24:33 Josef Reidinger wrote:

I think we should have registration/config for configuration and registration/status for registry (update of status from non-registered to registered is intuitive for me and it also can return current status if user is registered or not).

This is not possible. A client does not know if it is registered or not. You need to ask the registration server. The target system can ask the registration server but this means to run the registration again (which might include further interaction - you never know). Ciao, Daniel -- J. Daniel Schmidt SUSE Linux Products GmbH Research & Development Maxfeldstr. 5 GF: Markus Rex, HRB 16746 (AG Nürnberg) D-90409 Nürnberg -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

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 SUSE Linux Products GmbH Research & Development Maxfeldstr. 5 GF: Markus Rex, HRB 16746 (AG Nürnberg) D-90409 Nürnberg -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

J. Daniel Schmidt napsal(a):

On Monday 21 September 2009 17:17:27 J. Daniel Schmidt wrote:

...

...

Is there a state diagram available showing how requests and answers relate ? I'll create one.

Here are two diagrams showing how the registration is supposed to work: http://en.opensuse.org/YaST/Web/Development/Registration

Ciao, Daniel

Hi, Does information needed for registration need more steps or is sufficient to ask backend for needed arguments and then show it? If this is second case then you can send get to backend which return what parameters they need and then show this parameters and doesn't return (dynamic create content one time is possible, but longer session between user, frontend and backend is quite hard to do with stateless REST API). So I think that workflow for registration should be ask backend what information is needed -> generate form based on required arguments (rails have some support for this task) -> register if some error occure, then use error report and go from beginning (or let values in form it is not important). Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org