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 interface
network.setDomainname(....) network.setDefaultGateway(...)
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 pictures. Ciao, Daniel -- J. Daniel Schmidt <jdsn@suse.de> 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@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org