On 02/10/2011 01:14 PM, J. Daniel Schmidt wrote:
On Thursday 10 February 2011 18:44:48 Robert Schweikert wrote:
This is probably the heart of the difference in the design approach. In the system with the common lib, I as an implementer of a YaST module depend on someone else to provide the functionality I need in libyastcommon
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. If I have something that needs a config file but doesn't fit in with common lib I am screwed and have to find my own solution for a bunch of things that I shouldn't have to. Or I have to argue with a bunch of folks to accept my stuff into common lib. Neither is very appealing to me.
With the current model of YaST modules we all have to do implement it already. So we just rely on ourselves ... nothing to worry.
What used to be the "YaST module" is just the presentation of all this. (see my other eMail a few minutes ago)
Therefore, my implementation attempt requires me to first know that I have to implement stuff in multiple places (more than I would expect) and from a maintenance point of view I have to remember 6 month or more down the road that my implementation is splattered about.
This is how what we do currently as well. To solve one problem might require to implement functions within several modules. You might not even notice it but most current YaST modules are using parts of other modules - some just query data, some even change.
Not having the indirection of the common lib allows the module implementer to nicely contain everything in one directory (2 if a GUI is implemented).
... and would mean to lose the possiblity to offer a generic interface to both
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.
YaST and WebYaST. Both of them share the same common goals: - both do system configuration and management - both currently rely on YCP and want to get rid of it - both need an alternative way to do system configuration
These goals are met.
So why inventing something new in a way that only YaST can use it. And _if_ an interface would be added to the modules then WebYaST would rely on the YaST module directly - something we suffer from currently. Lets ratger depend on something that is light-weight, standardized and fast, and which can be used by the higher-level tools as they want.
I agree with "use something that is light weight" and "people can use as they see fit". That is exactly why I think a common lib is not the approach we want to take. I have not yet seen a common lib that tries to span a very large set of requirements be light weight, see my STL example below.
(WebYaST may only present a subset of the configuration options that YaST coult offer.)
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. 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.
Thus from a "casual" contributor and maintainer point of view I think a design without common lib is more approachable.
I disagree here. This approach seems to lead to a new SUSE-only solution again. Is this really something that we want?
No, I do not think we want a SUSE only solution, thus the importance of the language discussion in the other thread. As shown below my proposed architecture is not a SUSE only solution. Each module is distribution independent and can easily be picked up by any distribution that is interested.
Then why doing such big changes in the first place? If its only us writing and maintaining modules we could stay with YCP. Maybe somebody likes to add some new functionlatity and call it YCP++. But this would not solve any of our real problems.
Well, beside the fact that I'd have to pick up YCP (the language) my head was spinning after reading the tutorial for a few minutes because of all the moving parts I had to consider for the module I wanted to implement. My idea of doing this myself quickly deflated and I screamed for help. Lucky me, someone was willing to answer the call for help. A scenario like this shouldn't really be this difficult.
Right, and it wont with the new system. You implement all you need to to in the CL layer. Everything you need to read, write and execute on the system to solve the problem - in one standardized language. You don't even need to think about the UI presentation as this is something that the "new kind of YaST" module does. Once the CL functions are implemented you can design a nice UI to configure all options/steps.
This just sounds to me as if the CL is one big blob (and it is drawn that way as well) where everyone just throws their stuff in. This would according to my understanding look something like this import commonconfig So now I just picked up the interfaces for fiddling with a disk as well as the network, nfs, ntp, users, runlevel, you name it. Or in other words, I just loaded a bunch of stuff I don't want. And since everything is one glob my API documentation is a mile long, a pretty good way to make me not read it. I guess an example of a common library would be the STL. <sarcasm>Well, because the common implementation works so well there's also libboost to cover all the stuff that the divine inventors of the STL either didn't think of or couldn't be bothered to implement. But wait, maybe it will be implemented in the future and then something will move from libboost to STL.</sarcasm> How pleasant is it to work with that? In contrast the dynamic languages, with a modular design. You get a set of base modules "for free" when you install the core implementation and you can pick up a gazillion modules on an as needed basis.
From my point of view this is more easy than the current mixture of UI elements and system calls within the same YCP file.
I am not proposing to keep YCP or the current arrangement. I am trying to highlight the differences in the ASCII art architecture proposal and the one I had sent prior to that. The heart of the difference appears to be a unified common library (ASCII art proposal) vs. a more modular approach.
IMHO this is something that needs to be separated. We just learned about all the benefits of this approach when writing WebYaST in Rails.
- Your GUI code goes here: SOME_YaST-DIRECTORY ~ import yast3.gui_elements ~ use commonly known elements such as text area, buttons etc. - Your backend code (code that touches configuration files) goes here: SOME_OTHER_YaST-DIRECTORY inside a directory with a name to your liking. ~ Take a look at the API documents found here: SOME-LINK and try to reuse existing modules as much as possible ~ implement away and "Have a lot of Fun" :)
There you go, MVC paradigm, 2 moving parts, 2 locations to implement code.
When I look at my Rails apps I see all my Models collected in _ONE_ directory, in another I have all my Controllers collected in _ONE_ directory and I have all my Views collected in _ONE_ directory. With your approach we would have all models, all views all controllers spread around in mixed up in the modules directory.
Nope, sorry I don't think you understand what I am advocating. The module I implement (backend that fiddles with the config files I want to control) is implemented in 1 and only 1 directory. The location of the parent directory and what else is in the parent directory is rather immaterial to my implementation. Should I decide that I want a UI (Toolkit based, Web, or CL) frontend for my module I once again implement this in a directory that is "controlled" by me, and again the parent directory and it's location is rather immaterial. Preferably there would be some sort of module I can import to provide common GUI elements and this module should know how to display in ncurses etc. so I as a module developer do not have to worry about this, but that's convenience infrastructure, and any given distribution can decide to implement and brand this or not.
Is this really MVC like and is this easy to maintain and learn about? Thinking of models depending on other models, controllers using other controllers my head starts to spin around if I have to go and look them up on different places, maybe even search for them because its name does not indicate where it belongs (this is what we currently have with the YCP modules).
Again, I don't think you follow what I am trying to express. The architecture I propose is nothing else, and again borrowing from python, than import yast3.firewall As a developer wanting to use the module I don't really care whether the module I just imported lives in site-packages, some YaST directory, or other. I don't even care if what I just imported is implemented in C/C++, Python, or whatever (although I think pretty much everyone is in agreement that we want to stick to one language here). All I worry about is the documented interface of the module I just imported. And if I choose to, I can even decide to disable functionality if the import failed (see my earlier post, other thread I think). In this use case I can be a developer that works on a Web based UI, a toolkit based UI, or a command line frontend. In either case I get a hold of the configuration functionality in the same way. Now if I look at it from the other side of the coin, i.e. as the developer of the firewall module, I can stick my implementation in a directory called firewall in the parent directory of choice. This is completely distribution independent. In SUSE the module (directory containing the implementation) might live inside a directory named yast3 and on Fedora it might live in a directory named fedora-config. All fedora-config has to have is an empty __init__.py (and there is probably something similar for Ruby, or whatever language we end up with). The configuration module I just implemented is distribution independent. As a module developer I can control distribution dependence in my module by looking for config files in the expected places per distro and I am not dependent on the devine intuition by someone implementing a grand unified common configuration library.
I'd vote to bring the models together and offer a common lib.
I guess the bottom line is that I do not believe a common lib can be all encompassing and will cover every configuration I might possibly come up with in the future. Once I hit something that the implementer of the common lib has not thought off I am screwed. Now I have to figure out how to get something into the common lib. You just lost me as a contributor. Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Novell-IBM Software Integration Center LINUX Tech Lead rschweikert@novell.com rschweikert@ca.ibm.com 781-464-8147 Novell Making IT Work As One -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org