[yast-devel] Webyast session with consultant
Hi, I bring notes from today's session with consultant. We look at test-driven development. Usual presentation which can be also find on net, so nothing especially interesting. We try shoulda gem, which is quite good for reporting problems (test reports looks better). I ask also how to move our 2.2 generated rails to 2.3. Karel says that rails from 2.2 have templates which can generate code better (really good for business convence, so we should create some template for webyast plugins) and maybe exist some template to convert generated application. I google it and write result. Second think which we learn is how to work routes. especially interesting methods for rest is method resources and resource (and parameters only and except). Also we look how REST work. What Karel find strange is that we have default route, which often lead to unintended routes and behavior. Second what he think is that we should use route for each plugin as each plugin should define its routes which it provides. 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-... ). Rest tutorial is at http://www.infoq.com/articles/rest-anti-patterns and http://www.infoq.com/articles/rest-introduction 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. 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). Welcome any another ideas which I forget mention. -- Josef Reidinger YaST team maintainer of perl-Bootloader, YaST2-Repair, webyast modules language and time -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
* Josef Reidinger <jreidinger@suse.cz> [Aug 25. 2009 15:25]:
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
On Tuesday 25 August 2009 15:36:07 Klaus Kaempf wrote:
* Josef Reidinger <jreidinger@suse.cz> [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
On Tue, Aug 25, 2009 at 03:57:12PM +0200, Martin Kudlvasr wrote:
On Tuesday 25 August 2009 15:36:07 Klaus Kaempf wrote:
* Josef Reidinger <jreidinger@suse.cz> [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 ?!
YaST::ServiceResource being so complex and obscure that a trivial change took me the whole of yesterday. Debug this: #<#<Class:12345>:54321>
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
-- Martin Vidner, YaST developer http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
* Martin Kudlvasr <mkudlvasr@suse.cz> [Aug 25. 2009 15:57]:
On Tuesday 25 August 2009 15:36:07 Klaus Kaempf wrote:
* Josef Reidinger <jreidinger@suse.cz> [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
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". -- Duncan Mac-Vicar P. - Engineering Manager, YaST SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
* Duncan Mac-Vicar Prett <dmacvicar@suse.de> [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
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? -- Duncan Mac-Vicar P. - Engineering Manager, YaST SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- 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
* josef reidinger <jreidinger@suse.cz> [Aug 26. 2009 13:45]:
we should prefer using namespaces for routes - http://api.rubyonrails.org/classes/ActionController/Routing/RouteSet/Mapper....
The resource registration code in webservice is using namespaces _if_ the controller is within a namespace. And the latter is required if we want other contributors to ship their own implementation. See "namespace for controllers (high)" in the current TODO list. Btw, I've spend quite some time looking at different possibilities for routing and still believe the current solution is the best given the contraints. Keep in mind that routing in Rails is not(!) stored as urls (pathes), but as controller/action combinations. The dispatcher parses the requested url and tries to match it with stored controller/action pairs. Namespaces for routes require the controller to be 'namespaced' (inside a Ruby 'module'). 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
On Tuesday 25 August 2009 15:18:42 Josef Reidinger wrote:
For REST we should look how is designed cloudkit ( http://getcloudkit.com/ and
I fully agree with this part, which has little to do with CloudKit more than being a good example of functionality designed using rack middlewares By mastering Rack middlewares one can plug stuff like caching, logging etc really easily in the application without dealing with plugins, generators etc. CloudKit was quite original in implementing openId, oauth and even a dynamic RESTful storage layer as a Rack Middleware so you can do something like config.use.middleware 'CloudKit::Service', :collections => [:notes, :todos] and that middleware is inserted before your app (ActionController::Dispatcher.new , also a Rack component) is run. So if you request the url /notes, then the CloudKit middleware takes over and simulates an existing resource by using a schema free json storage. Having such a design bring great possibilities, however I would like more concrete advice on where to take advantage of it. Resource discovery is a good candidate, and I am researching whether serving assets from plugins may be possible. (good read on the topic http://www.slideshare.net/LittleBIGRuby/rack- middleware-1416040 ) -- Duncan Mac-Vicar P. - Engineering Manager, YaST SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
participants (6)
-
Duncan Mac-Vicar Prett -
josef reidinger -
Josef Reidinger
-
Klaus Kaempf -
Martin Kudlvasr -
Martin Vidner