On Tuesday 25 August 2009 15:36:07 Klaus Kaempf wrote:

* Josef Reidinger [Aug 25. 2009 15:25]:

...

We also talk about our webclient and what we should improve. We should have webclient also rest. Especially we should operate easy on hosts. Karel propose have sub-resources. So url should look like /hosts/1/systemtime for setting systemtime on first host.

Agreed, but its simply out of scope for the first deliverable.

...

Also we give another hints how to change our dynamic creating ActiveResource to normal classes and have in each plugin usual model, which should contain a lot of functionality and can be easily tested. (So we should have something like YaSTController as ancestor and YaSTResource as model ancestor).

This is tempting but I wonder which of our current problems is solved by this ?!

We were driven by the idea of having webclient as restfull as possible. In particular we would get rid of storing "site" in session. Martin Kudlvasr

Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)

-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

* Martin Kudlvasr [Aug 25. 2009 15:57]:

On Tuesday 25 August 2009 15:36:07 Klaus Kaempf wrote:

...

* Josef Reidinger [Aug 25. 2009 15:25]:

...

...

Also we give another hints how to change our dynamic creating ActiveResource to normal classes and have in each plugin usual model, which should contain a lot of functionality and can be easily tested. (So we should have something like YaSTController as ancestor and YaSTResource as model ancestor).

This is tempting but I wonder which of our current problems is solved by this ?!

We were driven by the idea of having webclient as restfull as possible.

There are two sides of 'restful'ness on the webyast client. The 'front' side serving html to a brower and the 'back' side talking to the service client. I believe the 'back' side is already restful and I fail to see the need of going restful for the 'front' side.

In particular we would get rid of storing "site" in session.

How's that ? Please elaborate. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

* Duncan Mac-Vicar Prett [Aug 26. 2009 11:01]:

On Tuesday 25 August 2009 17:04:09 Klaus Kaempf wrote:

...

How's that ? Please elaborate.

In the client side right now if you want to change the time of the host, you do a GET /systemtime which in turns does a GET in the service, interpret the xml and then render the html. Then a put is done to /systemtime when clicking "Save" and that generates a put in to the service.

Now, the service.. where? well, the "site" of the ActiveResource stuff is stored in the session and comes from the login. That is why we have /systemtime in the client, otherwise you could not know to what host to get the time from.

Karel is propossing that the host is part of the client url, so /host1/systemtime show the same controller and html than /host2/systemtime, but one calls different service urls than the other. Therefore fully "stateless".

Ah, now I get it, thanks ! Well, I agree with the proposal in principle but changing this has a couple of more consequences I fear. Like reworking the complete authentication/session stuff. Actually, that's something for a future version of WebYaST which should use something like http://code.google.com/p/rolerequirement But this needs a deeper discussion with the security team. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Duncan Mac-Vicar Prett napsal(a):

On Tuesday 25 August 2009 15:18:42 Josef Reidinger wrote:

...

another hints how to change our dynamic creating ActiveResource to normal classes and have in each plugin usual model, which should contain a lot of functionality and can be easily tested. (So we should have something like YaSTController as ancestor and YaSTResource as model ancestor). Welcome any another ideas which I forget mention.

That is possible, the only reason why we ask for the proxy object instead of having a model is because the path is variable, so proxy_for makes first a request to resources.xml and then sets the right path for the resource.

In a more RESTful model like making GET /:host/time go to TimeController#show and pass host as a parameter, one would still need to set the host all the time. Any idea how to make less repetitive?

Yes, we discuss it and possibility is use YaSTController ancestor and YaSTModel ancestor where in YaSTController is beforefilter which set site in YaSTController. This also set this var to its childs so it works good (acts same as usual ActiveResource). Also YaSTModel should contain permissions and other YaST rest related stuff. What is still unclear for me is specific path for interface. I think that it is not so hard use common ActiveResource mapping modelname -> path on site. I think that sollution in http://kkaempf.blogspot.com/2009/05/designing-restful-api-for-yast.html is not good, we should prefer using namespaces for routes - http://api.rubyonrails.org/classes/ActionController/Routing/RouteSet/Mapper.... . Then we need no magic with interface and have common ActiveResource code. So we should remove interface and only have permissions key (as now interface is identic with permissions path) Another think which Karel demonstrate on cloudkit is usage of request type OPTIONS which get description of provided REST api and which we should include to document our REST api. Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org