Mailinglist Archive: yast-devel (177 mails)

< Previous Next >
Re: [yast-devel] Direction of YaST Architecture?

On 02/10/2011 09:25 AM, Thomas Goettlicher wrote:
On Thursday, February 10, 2011 02:50:46 pm Robert Schweikert wrote:

Without a clear picture of the architecture that everyone can work from
you end up with something that is cobbled together and the pieces never
fit properly.

The implementation steps should be on the smallish side, no question.
But there ought to be a big picture showing the "macro architecture" if
you will, maybe something like the attached diagram.

The everyone can work on their own little piece of the world but with
the big picture in mind. That way things will fit together. Having
something like this ought to make it easier to make decisions about the
moving parts.


Your attached diagram looks similar to the overview designed by jdsn and me:

+---+---+---+---+ +--------------+
| 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 |

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?

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.
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


and then have the domain specific interfaces available as in


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.


Novell-IBM Software Integration Center LINUX
Tech Lead

Making IT Work As One
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