On 02/10/2011 11:28 AM, Klaus Kaempf wrote:
* Jiri Srain<[email protected]> [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: [email protected]
For additional commands, e-mail: [email protected]
