Mailinglist Archive: yast-devel (177 mails)

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


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@xxxxxxxxxx
rschweikert@xxxxxxxxxx
781-464-8147

Novell
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