On 02/10/2011 11:28 AM, Klaus Kaempf wrote:
* Jiri Srain<jsrain@suse.cz> [Feb 10. 2011 08:59]:
I'd target higher here: D-Bus based interface can be only local, for WebYaST we have the REST API on top of D-Bus anyway, so why not use it?
Thinking about it, I would propose to drop the WebYaST REST API as it is currently.
It is too low-level and should be replaced by a richer / more functional approach. It exposes YaSTs SCR layer, while it should expose the YaST 'module' layer.
The SCR layer handles 'disks', 'shell commands' and 'config files'.
Right now the WebYaST REST API is a CRUD REST API for the the models: User, Service. I think what can be dropped is having the API in a separate server and have the API in the same server as the web UI (same controllers /different content-type). Then the controllers and YaST could reuse this "models" (ie: if written in ruby), those models could be grouped in standard gems, and implemented on top of dbus, comar, or plain augeas. WebClient def index render Service.all :format => content-type end Desktop YaST dialog printing Service.all as table CLI YaST colored ANSI table printing Service.all class Service def find ... augeas or dbus code ... end end If one day you need remoting capabilities like Jiri suggested, you provide a implementation of class Service consuming the REST API WebClient exposes, or remote dbus, whatever. You can tackle that problem when you need it. It is not like we used much the current YaST remoting capabilities until now. Lets not limit ourselves because something we don't need right now. -- Duncan Mac-Vicar P. - Novell® Making IT Work As One™ 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