On Wed, Sep 09, 2009 at 10:58:03AM +0200, Jiri Srain wrote:

mvidner: - cooperation with Karel

I've pushed what we achieved during yesterday as a branch use-activeresource in the client: http://git.opensuse.org/?p=projects/yast/web-client.git;a=shortlog;h=refs/he... It still needs features and refactoring, but it already - fixes ActiveResource::Base.find :one (by adding the "else" to the "case") - can access /permissions.xml while being more readable. -- 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

On Thursday 10 September 2009 08:08:45 Klaus Kaempf wrote:

* Martin Vidner [Sep 09. 2009 18:09]:

...

On Wed, Sep 09, 2009 at 10:58:03AM +0200, Jiri Srain wrote:

...

mvidner: - cooperation with Karel

I've pushed what we achieved during yesterday as a branch use-activeresource in the client: http://git.opensuse.org/?p=projects/yast/web-client.git;a=shortlog;h=refs /heads/use-activeresource

It still needs features and refactoring, but it already - fixes ActiveResource::Base.find :one (by adding the "else" to the "case") - can access /permissions.xml while being more readable.

Can you enlighten us which problem this fixes and some background on the solution ?

The original YaST::ServiceResource was done to overcome the following limitatons: - ActiveResource not supporting singleton resources (find :one) - Automatic extraction of the path from the interface name - Gathering of resource permissions in order to enable /disable things in the user interface. However, it had a dynamic approach where you ask for the proxy instead of declaring a model class. I think Martin approach is saner and easier for Rails developers. I am not sure how he expects to un-hardcode the remote path prefix by using the interface, but I like the design of declaring the options in the model class itself, in the same style of has_many and so on, one could get something like with_interface "org.yast..." as an option to the path derived from the class. How to do a transition is unknown, but I guess one could use the new class as most resources are still being in / and we can transparently add the instrospection feature later. -- 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

On Thursday 10 September 2009 10:37:17 Klaus Kaempf wrote:

* Duncan Mac-Vicar Prett [Sep 10. 2009 10:19]:

...

I think Martin approach is saner and easier for Rails developers. I am not sure how he expects to un-hardcode the remote path prefix by using the interface, but I like the design of declaring the options in the model class itself, in the same style of has_many and so on, one could get something like with_interface "org.yast..." as an option to the path derived from the class.

Can you point us to a Wiki page explaining your approach and some example code showing the improvements over the current implementation ?

Please don't pollute the wiki with stuff that nobody will remember to cleanup later ;-). IMO the place for an example is the final module tutorial and unless the final approach is defined, the place for documentation is the comments above the class in Martin's branch. Mailing lists are fine for discussions and showing "examples". the main difference is, current solution: (client side) client = YaST::ServiceReource.proxy_for('org.opensuse.yast.network.interface') cards = client.find(:all) ... if not client.permissions.write? .. disable ui end Martin's solution (client side) class Interface < YastResource::Base has_prefix '/network' end then in the controller: cards = Interface.find(:all) Interface.permissions... And what we describe as missing features is the ability to do: class Interface < YastResource::Base any_that_implements 'org.opensuse.yast.network.interface' end instead of using has_prefix -- 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

On Thursday 10 September 2009 11:18:14 Klaus Kaempf wrote:

* Duncan Mac-Vicar Prett [Sep 10. 2009 11:03]:

...

And what we describe as missing features is the ability to do:

class Interface < YastResource::Base any_that_implements 'org.opensuse.yast.network.interface' end

instead of using has_prefix

Definitely.

Actually, there's no possibility to control the resource URI in Rails because it is assembled from the controller name and module (namespace).

But this means, that we'll have to solve controller name conflicts anyway. If 2 of our partners develop a plugin with the same controller name, there will still be a name conflict problem.

And that's why we've choosen the 'implements interface' approach because it doesn't require any knowledge about the implementation (controller name) of the service side.

I see, that the benefit of interfaces is, that we can have several webservice resources implementing the same interface. Webserver chooses the proper resource according to the supplied interface name. I think this is a good approach (although we will still have to solve interface name conflicts of 3rd party plugins). What I see as the problem is, that the translation from "interface name" to "resource URI" is not factored out. The webclient may want to ask for webservice resource URI, but certainly not about whether the resource is "singular" or "nested". For example I cannot imagine a webclient plugin, which would change its behaviour according to change of "singular" or "nested". This info is only needed by proxy_for, which tries to be universal and all- encompassing. I think that Martin's problem (...any_that_implements 'org.opensuse.yast.network.interface'...) can be solved by directly using ResourceController on webservice. Then use the path from resource[:href] to appropriately setup an ActiveResource (actually the enriched Martin's version YastResource). Martin Kudlvasr PS: Later it would be nice to be able to get a URI from interface in a RESTful way. Like: resources/org.opensuse.yast.modules.yapi.time instead of: resources.xml?interface=org.opensuse.yast.modules.yapi.time

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 Thursday 10 September 2009 14:41:28 Martin Kudlvasr wrote:

But this means, that we'll have to solve controller name conflicts anyway. If 2 of our partners develop a plugin with the same controller name, there will still be a name conflict problem.

You still can have controller clashes in the client, how do you expect to solve that?

PS: Later it would be nice to be able to get a URI from interface in a RESTful way. Like: resources/org.opensuse.yast.modules.yapi.time instead of: resources.xml?interface=org.opensuse.yast.modules.yapi.time

I feel we are now Java-ing the web :-) If the client still has the "controller unique name" problem, we should may be keep it simple on the service side too. I doubt someone building an appliance will intentionally want two /network/devices controller with same name and different APIs (they are still free to keep the API and change the implementation) Duncan -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

On 09/10/2009 11:02 AM, Duncan Mac-Vicar Prett wrote:

On Thursday 10 September 2009 10:37:17 Klaus Kaempf wrote:

...

* Duncan Mac-Vicar Prett [Sep 10. 2009 10:19]:

...

I think Martin approach is saner and easier for Rails developers. I am not sure how he expects to un-hardcode the remote path prefix by using the interface, but I like the design of declaring the options in the model class itself, in the same style of has_many and so on, one could get something like with_interface "org.yast..." as an option to the path derived from the class.

Can you point us to a Wiki page explaining your approach and some example code showing the improvements over the current implementation ?

Please don't pollute the wiki with stuff that nobody will remember to cleanup later ;-). IMO the place for an example is the final module tutorial and unless the final approach is defined, the place for documentation is the comments above the class in Martin's branch. Mailing lists are fine for discussions and showing "examples".

the main difference is, current solution:

(client side)

client = YaST::ServiceReource.proxy_for('org.opensuse.yast.network.interface') cards = client.find(:all) ... if not client.permissions.write? .. disable ui end

Martin's solution

(client side)

class Interface < YastResource::Base has_prefix '/network' end

then in the controller:

cards = Interface.find(:all) Interface.permissions...

And what we describe as missing features is the ability to do:

class Interface < YastResource::Base any_that_implements 'org.opensuse.yast.network.interface' end

instead of using has_prefix

I think that the most important difference is that we don't use any dark magic as now in resource_loader so it is easier to maintain. It is much cleaner to understand how it work. Second the most important improvement is that developer could add handling of resource to model, not to controller (excellent example is status controller, which contain many model functionality). Third one is that we use common rails convention, we have normal model without any magic and we add only few defined additions to that model in ancestor. That is idea, which any vendor developer know and can see. With resource_loader is hard even to find, that model is based on ActiveResource::Base so it has its methods, then find method for permissions (and find that permissions is not cached!) and find how it works is hard in current implementation. -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

present: kkaempf, dmacvicar, jdsn, schubi, mschmidkunz, visnov, jsrain, mvidner, mzugec, jreidinger kkaempf: - release planned this week - AI everyone: build and test your package dmacvicar: - trying to merge the log feature and pass to someone else jdsn: - REST API for registration, posted on mailing list schubi: - bugfixing in session and login stuff - TODO: laanguages RPM mvidner: - packaged network into buildservice - TODO: fix bugs after installation to a clean system mzugec: - network interfaces writing DONE - TODO: validation, test cases, packaging for SLES jreidinger: - NTP to separate back-end service - error handling in REST service mschmidkunz: - UI for Admin setting and Network -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org