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