Mailinglist Archive: yast-devel (177 mails)

< Previous Next >
Re: [yast-devel] Direction of YaST Architecture?
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.
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
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

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.
(WebYaST may only present a subset of the configuration options that YaST
coult offer.)


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

From my point of view this is more easy than the current mixture of UI
elements and system calls within the same YCP file. 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.

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

I'd vote to bring the models together and offer a common lib.


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