Mailinglist Archive: yast-devel (177 mails)

< Previous Next >
Re: [yast-devel] A Plan for YaST: Project Amaranth
  • From: "Duncan Mac-Vicar P." <dmacvicar@xxxxxxx>
  • Date: Mon, 14 Feb 2011 18:27:43 +0100
  • Message-id: <>
On 02/10/2011 11:28 AM, Klaus Kaempf wrote:
* Jiri Srain<jsrain@xxxxxxx> [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.

def index
render Service.all :format => content-type

Desktop YaST
dialog printing Service.all as table

colored ANSI table printing Service.all

class Service
def find
... augeas or dbus code ...

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@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >