Mailinglist Archive: yast-devel (177 mails)

< Previous Next >
Re: [yast-devel] Direction of YaST Architecture?
On Thursday 10 February 2011 23:21:17 Robert Schweikert wrote:

Attached is a revision of my original diagram incorporating some of the
design style of the ASCII art above.

Differences:

- There is no lib common, the lib common layer of the ASCII art diagram
is implemented by a modularized layer called "Configuration Modules".

You only gave it another name.
I never said that the thing Thomas an I called "common lib" should be one
blob, that any module has to load even if does not need it.

We didn't even say anything about how such stuff could be implmented or
organized. Your attached image basicall shows what we meant. Thank you for
colorizing it :)


- There is no lib-shell. In the modularized approach a power user can
import/use any module implemented in the "Configuration Modules" layer
directly, no need for additional indirection.

These was just a name as well - an idea we had during the brainstorming.
Please see all of this as such.
If your "configuration modules" can be used by other tools this is perfectly
fine. Thanks for giving it a better name.


- No "yast modules" as in the ASCII art, I believe these are superfluous.

Again, this was just to show that we wanted to separate the view from the
model. I guess that you also agree that this this should be possible with the
collection of the "Configuration Modules" as well. I mean specifically that a
third party tool can import one single "YaST3 configuration module" and should
not rely on any (Y)UI related stuff by doing this.


Additional notes:

- Policykit integration would just be another module in the
"Configuration Modules" layer

This already was in our ASCII art :)

- Zypper integration could be a SUSE specific module in the
"Configuration Modules" layer, other distros would implement their own
package manager integration module (although the API of this module
would have to specified and be consistent across distributions)

The thing in brackets was the only reason why we called it "common lib".


Reading your comments I really think that we basically meant the same, but
just called it differently. Your yast3Arch_rev2.png is pretty much the same as
our ASCII art, just with other names and more details.


Ciao,
Daniel

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