* Josef Reidinger
Hi, I bring notes from today's session with consultant.
Thanks. These notes are quite interesting and helpful !
Second what he think is that we should use route for each plugin as each plugin should define its routes which it provides.
We deliberately decided against this approach in order to make service plugins really 'pluggable'. A service plugin just defines an interface and the client side request this interface. All routing is then completely transparent. See http://kkaempf.blogspot.com/2009/05/designing-restful-api-for-yast.html for a discussion of this topic.
For REST we should look how is designed cloudkit ( http://getcloudkit.com/ and http://www.bestechvideos.com/2009/06/04/pivotal-labs-talks-cloudkit-hacking-...).
Hmm, at first sight this seems to conflict with ActiveResource. It probably needs a closer look though ;-)
Rest tutorial is at http://www.infoq.com/articles/rest-anti-patterns and http://www.infoq.com/articles/rest-introduction
http://delicious.com/kkaempf/rest has some more links on this topic.
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 ?! 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