On Thursday 10 February 2011 17:36:00 Johannes Meixner wrote: On Feb 10 15:25 Thomas Goettlicher wrote (excerpt):
Your attached diagram looks similar to the overview designed by jdsn and me:
+---+---+---+---+ +--------------+ | 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 | +--------------------------------------------------------------+
I think I understand Robert's attached diagram but I know that I do not understand your overview.
This diagram was the result of a discussion Thomas and I had yesterday.
Without some additional explanation it is just some nice Ascii-Art :)
So let me explain what we discussed:
The "Common Lib" can be seen as the new SCR. The CL knows how to do
configuration tasks in the system. Here is the intelligence that knows how to
parse all kinds of cryptic config files, start, stop, insert, remove
services... aso.
We wanted to solve these goals with this approach:
Better desktop integration of the modules
-------------------------------------------
The module can be integrated into different desktops more easily by running
all modules with user privileges (without exception). All configuration calls
are done via the CL that integrates polkit to check if this specific user is
allowed to do the change.
Attract external developers and distros
-----------------------------------------
We want to attract other in our community to help and from other distros to
also use the CL. Thus it needs to be able to run on _all_ kinds of linux
systems. So the implementation of the config tasks might differ from distro to
distro, but the calls from the modules above do not change. See it as a
standardized API to to do configurations.
Tranparently offer all CL tasks to WebYaST
--------------------------------------------------
The CL could run a tight attached webservice to offer all tasks as REST
service. No developer of a CL task should need to do anything for the
integration in the web service, as all tasks of the CL are available via the
REST interface as well (automagically).
Offer simple scripting interface
----------------------------------
The CL offers a shell or scripting interface to easily allow any third party
tool to configure what it likes without the need to rely on any YaST module.
All configuration tasks could be done directly by using the CL API. YaST
modules are just one abstraction layer that intelligently combine several
configuration steps (tasks) into a workflow to solve a problem.
Example: A user wants to add a samba share. The "Shares" module finds that
samba is not installed, offers to install it, opens the port in the firewall,
and then does the remaining samba configuration. This is an abstraction to
ease the single tasks for the user. Experts (or scripts) who know what to do
can use the shell directly.
Btw. LibShell is not a replacement of the current commandLine interface. This
interface still relies on the module and can use all its magic and dependent
configuration tasks.
Make the new YaST available for other distros
----------------------------------------------
We can offer the system to any other distro. They only need to implement the
distro-specific differences into the CL tasks and they would get 6 UIs for
free (shell, cmdline, Qt, gtk, ncurses, web). This also means that the YaST
modules shoud never do system calls directly, as each task may be different on
another distro. Thus "zypp" integration as mentionend above maybe misleading.
We meant a generic interface to the package management - this may be
packagekit talking to zypp, on other distros this might be something
completely different.
So the new kind of YaST modules are very similar to the current webyast web-
client modules - they just care about the proper presentation of depending
tasks to solve a problem. The CL can be seen as the data model that is to be
queried and changed.
All these goals are goals for the long run. They are not the reason why we
discuss about this change. But if we are in the discussion of a change anyway
and even think about radical changes (like dumping a language and
consolidating to a new one), then lets think big and see how perfect we can
be and how we could attract others as well.
When we do only very little changes to the existing system and create the new
one in a way that it cooperates perfectly with the current YCP based one we
would inherit all burden of the current system. We would not gain a lot
besides just to have a new language.
My dream of a new YaST is a system that does not remind anybody of YCP once we
dropped YCP support/bindings. So lets design the system as good and clean as
we can, using best practices of the new language, and without "thinking in
YCP", and then lets see how it could be connected for the time of the
transition.
Ciao,
Daniel
--
J. Daniel Schmidt