Mailinglist Archive: yast-devel (177 mails)

< Previous Next >
Re: [yast-devel] Direction of YaST Architecture?
On Thursday, February 10, 2011 05:36:00 pm Johannes Meixner wrote:

On Feb 10 15:25 Thomas Goettlicher wrote (excerpt):
Your attached diagram looks similar to the overview designed by jdsn and
+---+---+---+---+ +--------------+

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




I think I understand Robert's attached diagram
but I know that I do not understand your overview.

Thank you for giving me the opportunity to explain the diagram.

The common lib provides an api for system configuration. E.g. it allows to add
a new print queue, it knows which files to touch and checks user's
permissions. It doesn't know anything about the presentation to the user.
That's the yast module's task. It assigns the common lib's methods to input
widgets shown by libyui (qt,ncurses,gtk).
The positive aspect is that other frontends like webyast also can use the
common lib for system configuration. Even other distros might use the common
lib and build their own config frontends on top of it.

All what I pick from your overview is that when I want
to make a yast module for my specific config task,
it would be insufficient.

I see that additionally I have to care about stuff
like "rest service" and "lib shell" (whatever this is)
and I fear that I have to implement at least parts of my code
up to tree times - I won't do this - I would simply give up.

Furthermore I would be hit by whatever shortcoming
of the "common lib" which seems to sit in between my code
and the actual SYSTEM that I want to change. The "common lib"
may not exactly provide what I need for my specific config task
so that I would have to implement whatever workarounds...

This YaST thingy is both insufficient and too complicated for me.
I will write my own setup tool in my own preferred language.
I know how to do it so that the tool does what I want.

If you like you could use me as some kind of "test case"
whether or not an individual contributor would like
to join the project.
Great! Thank you for your support. It makes sense to design a framework that
can be used in the end.

What I mean:
The more the whole stuff is complicated (or oversophisticated),
the less likelihood that someone gets sufficiently interested
to actually contribute something.

Or in other words:
If the first attempt to make a simple setup tool fails
because the whole stuff is too complicated,
it was probably the last attempt.

Kind Regards
Johannes Meixner

Thomas Goettlicher
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >
List Navigation
This Thread