Mailinglist Archive: yast-devel (177 mails)

< Previous Next >
Re: [yast-devel] Direction of YaST Architecture?
On Thursday, February 10, 2011 04:16:53 pm Robert Schweikert wrote:
[...]

+---+---+---+---+ +--------------+

| Q | N | g | c | |webyast client|
| t | C | t | m | +------+-------+
|
| | | k | d | |

+---+---+---+ | http

| libyui | | |

+-----------+ +-----------+---+ +------+-------+

| lib shell | | yast modules | | rest service |

+-----------+--------+---------------+----------+--------------+

| common lib: reads/writes config files, starts/stops services |
|
| integration of polkit and zypp |

+--------------------------------------------------------------+

| SYSTEM |

+--------------------------------------------------------------+

Perhaps rest service should sit on top of yast modules.

I am not sure what to make of the common lib and whether the additional
indirection is needed. Why would a YaST module not write the
configuration files it is responsible for directly?
In this diagram the yast module tell the common lib e.g. to create a samba
share called "foo". The common lib checks whether the user is permitted and
changes the config files and restarts the samba service.
The yast module is responsible for the visual presentation and has not to care
of technical details.


I suppose "lib shell" is the API for scripting? If yes, that would
appear to be too close to the point where the rubber meets the road.
There are two scripting interfaces. The first is called "cmd", it's the same
as the current YaST scripting interface. The second is "lib shell". it allows
to do all system config without YaST (UI) modules. Other distros might use.


IMHO we want scripting to occur on top of the YaST modules and ideally
have the YaST modules setup such that they can be imported into whatever
language we end up with. As shown in my implementation proposal in Python

import yast3.NAME_THE_CONFIG_MODULE

and then have the domain specific interfaces available as in

yast3.ntp.setNtpServer(....)

In short I see the introduction of the "common lib" as a very big
difference in the architecture diagrams.

Note that I am not saying that there is no code that may be shared
between some or all YaST configuration modules. All I am saying is that
there is probably no need for another level of indirection. Code common
to some or all YaST modules (such as the modified file detection for
example) can be shared if this common code is simply implemented as a
module at the same level as all the other YaST configuration modules.

Robert

--
Thomas Goettlicher
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 >
List Navigation
This Thread
Follow Ups