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 <jdsn@suse.de> 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@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org