Mailinglist Archive: yast-devel (177 mails)

< Previous Next >
Re: [yast-devel] Direction of YaST Architecture?
On Thursday 10 February 2011 21:17:03 Robert Schweikert wrote:
Nope. Its you, the developer of the configuration task.

Exactly my point, as the implementer for the configuration module I am
willing to write and maintain, I have to stick my stuff into the common
lib. The ASCII art diagram does not allow me to interact with the system
without going through common lib.

The thing we called "common lib" _IS_ directly interacting with the system.
Put everything that you need to interact with the system together in a (lets
call it) plugin that gets part of the "common lib". Don't thinkt of "common
lib" as a thing that someone else is maintaining and you should rely on him.

It's us, YaST developers, who extend the "common lib" with new functions (yes,
sure, they should be stable and persistent in order not to brake existing
configuration modules).

The only reason why we separated the CL and the thing we called "YaST modules"
in the ASCII art was, to show the separation of the model and the view. This
would allow to run the view with user privileges and better desktop
integration if a desktop-specific tool decides to use the CL directly.

If I have something that needs a
config file but doesn't fit in with common lib I am screwed

I don't see why any such thing should not fit in CL?
The CL is _the_ place to put it.

The implemented module provides the domain specific interface used by
all clients, YaST (in QT, Gtk+, or whatever toolkit), WebYaST (or other
Web UI), a CLI tool.....

Nothing is lost. The module (notice the box in my diagram says
"Configuration modules" not "YaST modules") hides the specifics of
individual or multiple config files behind a domain specific generic


for example.

Ok, then I guess I misunderstood your initial description and just miss the
separation of model and view in your original picture.

Yes, but yet in the ACSI art diagram WebYaST still would depend on the
glob of the common library. Thus it would pick up the implementation of
a ton of interfaces that WebYaST does not provide any access to through
the web based interface.

We didn't say anything about how this is implemented.

In the other proposal WebYaST or any other client can pick and choose
from any modules in the "Configuration Modules" box. Only pulling in
those interfaces and the given modules dependencies.

That is exactly what Thomas and I meant. We just didn't draw many small boxes
in the "common lib" box (it already took long enough to get the ASCII art
formatted nicely ;) ).

This just sounds to me as if the CL is one big blob

No, we never said and never meant that.

After all I think in this discussion we too much interpret the drawings of
each other, seeing, expecting something that is not there. Sure, we even left
out some parts in our pictures (because for us they were too much detail).

For me the pictures are just a help to visualize something that I describe in
words. The description for me is more important. So please lets rather focus
on what we write next to the images and graphs than to compare them.

And I can only repeat myself: I think we really want the same thing, we just
call it differently. That's why it's good to have descriptions next to the


J. Daniel Schmidt <jdsn@xxxxxxx> SUSE Linux Products GmbH
Research & Development Maxfeldstr. 5
GF: Markus Rex, HRB 16746 (AG Nürnberg) D-90409 Nürnberg
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