Mailinglist Archive: yast-devel (177 mails)

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


On 02/10/2011 11:28 AM, Thomas Goettlicher wrote:
On Thursday, February 10, 2011 04:16:53 pm Robert Schweikert wrote:
[...]

+---+---+---+---+ +--------------+

| Q | N | g | c | |webyast client|
| t | C | t | m | +------+-------+
|
| | | k | d | |

+---+---+---+ | http

| libyui | | |

+-----------+ +-----------+---+ +------+-------+

| lib shell | | yast modules | | rest service |

+-----------+--------+---------------+----------+--------------+

| common lib: reads/writes config files, starts/stops services |
|
| integration of polkit and zypp |

+--------------------------------------------------------------+

| SYSTEM |

+--------------------------------------------------------------+

Perhaps rest service should sit on top of yast modules.

I am not sure what to make of the common lib and whether the additional
indirection is needed. Why would a YaST module not write the
configuration files it is responsible for directly?

In this diagram the yast module tell the common lib e.g. to create a samba
share called "foo". The common lib checks whether the user is permitted and
changes the config files and restarts the samba service.
The yast module is responsible for the visual presentation and has not to
care
of technical details.


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 (to give the child a name) or I have to implement stuff in
this common lib. 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.

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). I can still use policy modules (implemented at the same
level as my YaST module) by simply importing them and using the API, but
I do not have to change any code outside of my directory that implements
the module I am willing to implement and maintain.

Thus from a "casual" contributor and maintainer point of view I think a
design without common lib is more approachable.

So why do I care, or why should we as SUSE community care about the more
"casual" contributor/maintainer. Let me use myself as an example.

I was looking at opportunities to simplify and automate some steps of a
cloud install process. Thus, it was more or less natural that I'd look
to YaST and I figured I could add a module that would collect the
information needed for the cloud during first boot and then installing
other nodes in the cloud could be fully automated. After all, how hard
could it possibly be, right?

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.

In the new model I should just be able to implement my module without
having to consider a number of different places and moving parts.

I could see a tutorial (and now I am going of on a tangent, I realize
that) structured something like this.

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

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