* Arvin Schnell <aschnell@suse.de> [Jan 31. 2011 10:54]:

The currently generated bindings for libstorage are so bad that almost every function has handwritten make-it-usable-code in YCP. This hinders moving code from YCP to C++. Apart from that we even need workarounds in libstorage to avoid seg. faults since the bindings cannot handle C++ strings (that internally have pointers) inside structs.

Fully agreed.

And AFAIK the handwritten bindings for libzypp are always a bit outdated and lack features.

Thats why the libzypp-bindings are currently moving away from being generated automatically to a clearly defined API. It is a bit more work upfront but provides a couple of advantages like - dramatically reducing the size of the generated bindings (because almost all C++ type conversions can be dropped) - hiding the libzypp internals (who cares for 'zypp.ZYppFactory_instance().getZYpp()' ?) - make the API fit natural into the target language - backwards compatibility (provide the same binding package across multiple versions of libzypp) This is work-in-progress, see zypp-devel for details. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

On Jan 30, 2011, at 6:35 AM, Stanislav Visnovsky wrote:

...

1) Replace YCP with some common language? With more that 100 modules this looks impossible.

I think this is a good and the only viable option if YaST code should survive in long run.

+1. -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Hello, On Jan 30 14:35 Stanislav Visnovsky wrote (shortened):

On piatok 28 Január 2011 16:50:10 Arvin Schnell wrote: ...

...

1) Replace YCP with some common language? With more that 100 modules this looks impossible.

I think this is a good and the only viable option if YaST code should survive in long run.

For me this looks like a contradiction in itself because killing YCP would kill all code which is written in YCP. Stanislav, what did you actually mean? In general I think we should be very careful with exact wording. I.e. what exactly is menat with "YCP"? The language? The YCP runtime environment? The code which is written in YCP? I think before any discussion whether or not "YCP" can be replaced makes sense, there would have to be at least one single alternative which really actually works and which is already accepted by the free software developers "out there" who like to contribute to YaST. If and only if such an alternative exists, then it could make sense to set YCP "deprecated" so that no new YaST module would be created in YCP code. Then there would be a longer time of a "YCP fade out phase" where the YCP runtime environment must be maintained so that the old YCP modules can still run. During the "YCP fade out phase" the old YCP modules could be one by one and step by step re-written in whatever alternative language. Personally I don't care about alternative languages as long as the alternative really actually works. I trust that any decision of free software developers who actually contribute to YaST would be also o.k. for me. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex

Stanislav Visnovsky write:

On utorok 01 Február 2011 11:31:40 Johannes Meixner wrote:

...

Hello,

On Jan 30 14:35 Stanislav Visnovsky wrote (shortened):

...

On piatok 28 Január 2011 16:50:10 Arvin Schnell wrote: ...

...

...

1) Replace YCP with some common language? With more that 100

modules this looks impossible.

I think this is a good and the only viable option if YaST code should survive in long run.

For me this looks like a contradiction in itself because killing YCP would kill all code which is written in YCP.

Stanislav, what did you actually mean?

I mean YCP as programming language here. The only viable alternative is to , as you write below, phase it out:

I agree.

1) introduce single alternative common programming language as 1st class citizen

Maybe it could be interesting to define our requirements on language. from my POV it should: 1) be easy testable 2) high-level ( in general we don't care about programming language performance as we do many time consuming tasks and if we need good performance in some part then use bindings (see below)) 3) easy debugging (it is really annoying debug ycp via debugger) 4) easy profiling (it is hard to find bottle neck) 5) easy bind libraries, especially in C and C++ 6) object oriented with exception ( it is related to 2 as it would be great if we can easy share object ( now we share functions and global variables and it is sometime really pain. Exception is good for error handling. It e.g. allow easy decide if error is from user or programmer and allow proper error message) 7) have at least medium community and codebase so we are not alone to maintain it or be one of two maintainers 8) be enough mature, so we don't need to fight with language 9) allow easy sharing code like python eggs, ruby gem or perl cpan so we can share our work where it make sense and have more users ( or easy use same code also in other our products - just try remember if other our product use any code written in YCP)

2) move the codebase from YCP to this language, doing easy refactoring tasks where applicable (keep YaST as whole working)

Also for codebase have good test coverage and clear purpose of all methods. Also sometime clean public API could be good (try to keep it simple :).

3) deprecate YCP as programming language

Yes, make sense.

4) look at architecture from perspective of the new codebase and new language

Absolutely make sense, especially reconsider if we need SCR agents architecture. Also consider better MVC model then now. Especially if we want share model there should be no UI calls.

I'm fan of small steps, not grand plans for redoing everything from scratch.

agree, small steps which is finished is better then grand plan which is never finished completely

Actually, I'm willing to contribute as time permits.

I can help with codebase and do code review :) Pepa

Stano

-- Josef Reidinger Appliance Toolkit team maintainer of perl-Bootloader, yast2-bootloader and parts of webyast and SLMS -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

* Arvin Schnell <aschnell@suse.de> [Feb 01. 2011 13:03]:

10) Small runtime environment for installation medium.

The meaning of 'small' varies, depending on whom you ask ;-) Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

On Tue, Feb 01, 2011 at 12:48:57PM +0100, Josef Reidinger wrote:

...

1) introduce single alternative common programming language as 1st class citizen

Maybe it could be interesting to define our requirements on language. from my POV it should: 1) be easy testable 2) high-level ( in general we don't care about programming language performance as we do many time consuming tasks and if we need good performance in some part then use bindings (see below)) 3) easy debugging (it is really annoying debug ycp via debugger) 4) easy profiling (it is hard to find bottle neck) 5) easy bind libraries, especially in C and C++ 6) object oriented with exception ( it is related to 2 as it would be great if we can easy share object ( now we share functions and global variables and it is sometime really pain. Exception is good for error handling. It e.g. allow easy decide if error is from user or programmer and allow proper error message) 7) have at least medium community and codebase so we are not alone to maintain it or be one of two maintainers 8) be enough mature, so we don't need to fight with language 9) allow easy sharing code like python eggs, ruby gem or perl cpan so we can share our work where it make sense and have more users ( or easy use same code also in other our products - just try remember if other our product use any code written in YCP)

I agree with all of this, but the problem is that the only conclusion I can make of this list is that any of Python, Ruby, Perl is vastly superior to YCP. It does not help to choose among the 3. -- Martin Vidner, YaST developer http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu

Hello, On Feb 2 11:14 Klaus Kaempf wrote:

Actually, the underlying implementation language shouldn't matter too much to a developer using a future YaST infrastructure.

I would strongly suggest to look into the concept of domain specific languages and focus on systems managemen functionality instead of language specifics.

The key is to use concepts a systems administrator is familiar with.

To give you an example, lets assume we want to add a new harddisk as /abuild. The code could look like this

# create a new 'handle' to manage the disk disk = Disk.new "/dev/..."

# defaults to use the whole disk with ext4 disk.create_partition

# alternative # disk.create_partition :filesystem => :btrfs

disk.label = "Abuild"

# create a 'mountpoint' object # 'system' is a global object representing the target mountpoint = system.mkdir "/abuild"

# mount first disk partition, associates mountpoint object with partition mountpoint.mount disk.partitions.first

# create fstab entry, mountpoint has all required information system.fstab.add mountpoint

Those of you with Ruby knowledge will see the similarities ;-) And thats for a reason since Ruby is ideally suited to implement domain specific languages.

On first glance it seems you like to replace the YaST specific language YCP with another YaST specific language (which could be now implemented in Ruby). Klaus, could you describe in more detail what you actually mean? Perhaps you meant something like what I would like to have: I do not care about the language. I do care about the ready to use set of functions (or classes or whatever such stuff is called in the particular language) which are provided by the YaST development environment so that I could implement my particular YaST modules easily. When I learned YCP I was searching for its built-in functions to change the system (e.g. change config files and so on). But I found out that there are no such functions in YCP. On the one hand YCP is THE language to implement YaST modules but on the other hand YCP does not provide functions to change the system. Basically YCP is only about the user interface! Then I learned about this other stuff how to change the system. I do not care very much about how to implement the UI because I do not need sophisticated UI functionality. I would be more interested how to change the system. I would like an easy to use framework to change the system (and not an obscure ini agent which destroyed config files). Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

...

...

1) introduce single alternative common programming language as 1st class citizen

Maybe it could be interesting to define our requirements on language. from my POV it should: 1) be easy testable 2) high-level ( in general we don't care about programming language performance as we do many time consuming tasks and if we need good performance in some part then use bindings (see below)) 3) easy debugging (it is really annoying debug ycp via debugger) 4) easy profiling (it is hard to find bottle neck) 5) easy bind libraries, especially in C and C++ 6) object oriented with exception ( it is related to 2 as it would be great if we can easy share object ( now we share functions and global variables and it is sometime really pain. Exception is good for error handling. It e.g. allow easy decide if error is from user or programmer and allow proper error message) 7) have at least medium community and codebase so we are not alone to maintain it or be one of two maintainers 8) be enough mature, so we don't need to fight with language 9) allow easy sharing code like python eggs, ruby gem or perl cpan so we can share our work where it make sense and have more users ( or easy use same code also in other our products - just try remember if other our product use any code written in YCP)

I agree with all of this, but the problem is that the only conclusion I can make of this list is that any of Python, Ruby, Perl is vastly superior to YCP. It does not help to choose among the 3.

Also something to consider is in which platforms it should be usable. Gnome, KDE, +++ and also which HW platforms. Server? Desktop? Netbooks, Pads, appliances, mobile phones? Only considering Gnome/KDE and Server/Desktop would limit the possible userbase tremendously. Kind regards / Birger -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

On 02/02/2011 09:33 PM, Patrick Shanahan wrote:

* Birger Kollstrand<birger.kollstrand@googlemail.com> [02-02-11 13:20]: ...

...

Also something to consider is in which platforms it should be usable. Gnome, KDE, +++ and also which HW platforms. Server? Desktop? Netbooks, Pads, appliances, mobile phones?

I was of the opinion (?mistakenly?) that YaST# was an openSUSE tool, not a desktop specific application.

...

Only considering Gnome/KDE and Server/Desktop would limit the possible userbase tremendously.

This is a very important part because as Linux evolved and YaST stayed the same, the needs for YaST are different. Look at the desktop: Who needs sound configuration? In 2003 it was pretty useful, but nowadays I only used the module to enable or disable pulseaudio, which is a thing the user should not care about as this switch exists only because pulseaudio was broken. Printer? I don't remember configuring a printer since long time. They just show up. Network. I only use yast2 lan when I break my factory system's networkmanager. Package Management? See how beautifully integrated package management is in the KDE-4 user-mode control center. No root, simple interface. For something more advanced you have zypper, for something more friendly there is an appstore coming. The only parts I see relevant in _my_ laptop to setup via YaST is fingerprint reader because they don't work out of the box (why?). I also create users because there is some extra magic in the way YaST does it. May be firewall. However all the above could be done directly from the desktop, because you need app integration: ie, install P2P program, it should be able to open a port from the application. So what is really YaST role in the desktop? -- Duncan Mac-Vicar P. - Novell® Making IT Work As One™ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

On 02/03/2011 11:28 AM, Martin Kudlvasr wrote:

I tried the printer module and in handles printer sharing and behaviour. But not drivers.

If you click on add, it allows you to select drivers.

I use network to configure several tap interfaces and connect them by bridge. It's great for virtualbox and soooo easy to do in yast.

Oh yes, this is true. I also did this. But this is a developer's usecase, not a desktop user one.

...

Package Management? See how beautifully integrated package management is in the KDE-4 user-mode control center. No root, simple interface. For something more advanced you have zypper, for something more friendly there is an appstore coming. Cool! Are there similar tools for Gnome, console (ncurses), LXDE ?

Who cares. Desktop is not about ncurses, and including LXDE means you need to care about GNUStep, Etoile, etc. The list is infinite. Console users have zypper. Other desktop should write their own stuff on top of PackageKit, just like KDE and Gnome did. (note: for console you have pkcon as non-root as well)

Yes, once you focus just on a Desktop, your arguments make sense. But openSUSE so far is "universal". Once there is a split to openSUSE Desktop and openSUSE Server, there are many ways to optimize. This can be just part of the installation - do you want typical Desktop, Server, Expert's system ? The package selection should reflect that.

This is why I see openSUSE as Debian, and not as Ubuntu. It is a collection of packages without much coherence, but not a "product".

I understand your point - who needs Infrared device, Joystick attached to a sound card, DSL, ISDN, Modem these days? Many modules just display contents from some configuration file (fstab, hostname) without any higher abstraction. So the service they essentially provide is "syntax checking" (without a choice to override).

Yes. The best configuration at all is the automatic/nonexistant one.

To evolve to a more usable state I would suggest: for experts - syntax (& semantics) aware editor of config files for novices - a (much) higher abstraction (yes, it's hard)

For novices, if you need any configuration at all, it should be based on his knowledge. I remember mysql configuration: "What will you use this MySQL server for?" (o) Development environment ( ) LAN server ( ) Heavy loaded server facing the internet Depending on the selection, all tunings, security decisions, etc were made for you. A colleague also showed me a backup tool he wrote. I was surprised by some UI decisions we usually fail when the target is a newbie: Excludes: instead of wildcards, there where checkboxes with "Music", "Documents" "Videos". Frequency and versions kept: just a slidebar between Paranoid and not paranoid.

Yes, YaST is not that useful for novices on Desktop anymore. So let's make it a tool for experts.

I agree. Everything that is not for experts should work out of the box or configured once by asking a few questions. -- Duncan Mac-Vicar P. - Novell® Making IT Work As One™ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

On Thursday 03 February 2011 11:28:38 Martin Kudlvasr wrote:

I understand your point - who needs Infrared device, Joystick attached to a sound card, DSL, ISDN, Modem these days? Many modules just display contents from some configuration file (fstab, hostname) without any higher abstraction. So the service they essentially provide is "syntax checking" (without a choice to override).

There is one point about just dumb editors of configuration files: AutoYaST. Getting rid of these modules completly would also mean that we get rid of related AutoYaST functionality. And once we have the AutoYaST functionality, run-time functionality is, depending on particular case, mostly for free. However, I agree that there are modules which are not needed any more for none of YaST's use cases (e.g. ISDN module). Jiri -- Regards, Jiri Srain YaST Team Leader --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain@suse.cz Lihovarska 1060/12 tel: +420 284 084 659 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Hello, On Feb 3 08:21 Robert Schweikert wrote (shortened):

Yes, I could configure printers via the cups web based UI, but now I loose the integration.

What do you mean with "integration"? Do you perhaps mean that YaST provides the same kind of user interface for all its modules? Or do you perhaps mean that e.g. the YaST printer module "knows" the openSUSE printer driver package RPM names so that it can provide a dialog to install (or remove) them? Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

On 02/03/2011 02:21 PM, Robert Schweikert wrote:

This sounds like you are advocating for no YaST. However, not every system is a desktop, not every system uses Network manager, .... the list goes on. I find the printer module quite useful, as well as the network configuration....

No. I am advocating for as less YaST as possible... _on the desktop_.

Yes, I could configure printers via the cups web based UI, but now I loose the integration. Following this train of thought to it's logical conclusion leads to running 20 different tools for every configuration task, that sucks ! One of the strengths of YaST is the integration it provides.

What do you what to "configure"? I print every day and I have never configured anything. -- Duncan Mac-Vicar P. - Novell® Making IT Work As One™ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

I doubt that there are many users out there willing to maintain

On 02/04/2011 10:10 AM, J. Daniel Schmidt wrote: their own CUPS

server in order not to have to use a YaST printer module.

I am very glad to have the printer configuration module as I do not want to configure CUPS manually.

Yes you have a point there. OSX also uses CUPS, but the printer configuration is a small settings on the desktop and not a system wide configuration that you need first that it exists. I still wonder, if there is a printer database, why it is not possible to just plug the printer, have some rule match the id, pick the right ppd, adjust/restart cups, everything automatically (basically what Windows does if you throw the vendor CDs to the trash first). -- Duncan Mac-Vicar P. - Novell® Making IT Work As One™ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Off topic! Hello, On Feb 4 11:00 Duncan Mac-Vicar P. wrote (shortened):

I still wonder, if there is a printer database,

There is no such thing as a printer database where printer IDs of current USB printer models are mapped to printer driver descriptions (PPDs). As far as I know there is not any kind of database where something like SNMP printer IDs of network printes are mapped to printer driver descriptions. Lists of USB printer IDs and lists of SNMP printer stuff may exist and all what is missing is this tiny litte part to map them to printer driver descriptions. Of course nothing could be more easy.

From a theoretical point of view...

In practice this idea pops up every now and then but nothing had changed for many years - guess why! Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

On 02/04/2011 06:46 PM, Robert Schweikert wrote:

I think the OpenPrinting DB meets this need

http://www.linuxfoundation.org/collaborate/workgroups/openprinting/databased...

Yes, with that you could even tell the user if the printer will work at all, and download the driver. However, as YaST runs as root, there has not been much integration with the web. Something to fix. -- Duncan Mac-Vicar P. - Novell® Making IT Work As One™ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Hello, On Feb 4 12:46 Robert Schweikert wrote (shortened):

On 02/04/2011 11:48 AM, Johannes Meixner wrote:

...

Off topic!

Hello,

On Feb 4 11:00 Duncan Mac-Vicar P. wrote (shortened):

...

I still wonder, if there is a printer database,

There is no such thing as a printer database where printer IDs of current USB printer models are mapped to printer driver descriptions (PPDs).

I think the OpenPrinting DB meets this need

You think about your wishes - but you don't know about the reality. Any database and of course in particular the OpenPrinting database could do this - if someone added the data! Guess what: Even plain PPD files support this. Adobe wasn't stupid when the PPD spec. was made a long time ago. All what is missing is the actual data! There is no need for whatever additional databases to set up printers. Plain PPDs are perfectly sufficient. And in some cases it works already - what a surprise! But I a printer setup tool which only works in some cases is not what users really need. In those cases where automatic printer setup works there is obviously no need that a user runs a printer setup tool to set up his printer manually. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

On Tuesday, February 01, 2011 12:01:22 pm Stanislav Visnovsky wrote: [...]

I'm fan of small steps, not grand plans for redoing everything from scratch.

I fully agree. There already exists a project that is a complete new YaST without legacy code like YCP and it uses a cool and object oriented script language. It's called webyast. :-) For YaST I think we shouldn't try to refactor everything for the sake of refatoring. We already have a robust framework, let's focus on how we can add benefits for the users to YaST, e.g. the snapper feature. If the implementation of this feature needs architectural changes I totally fine with it. Thomas -- Thomas Goettlicher SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

On Wednesday, February 02, 2011 10:03:19 am Martin Vidner wrote:

On Tue, Feb 01, 2011 at 03:01:19PM +0100, Thomas Goettlicher wrote:

...

On Tuesday, February 01, 2011 12:01:22 pm Stanislav Visnovsky wrote: [...]

...

I'm fan of small steps, not grand plans for redoing everything from scratch.

I fully agree.

There already exists a project that is a complete new YaST without legacy code like YCP and it uses a cool and object oriented script language. It's called webyast. :-)

That is not true. Many (8?) WY modules use YaPI to call legacy YaST, for better or worse. ls YaST:Web/*/*.pm Okay, let me rephrase my statement: There already is a yast-project that uses ruby and tried to get rid of YCP.

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

On Mon, Jan 31, 2011 at 10:53:51AM +0100, Klaus Kaempf wrote:

Arvin,

thanks a lot for stepping forward and starting this dicussion !

* Arvin Schnell <aschnell@suse.de> [Jan 28. 2011 16:50]:

...

So what seems desirable and feasible? Some ideas:

Which goals would you achieve by implementing these ideas ?

From the company point of view I see these goal: - Keep YaST maintainable with a few people, not necessarily those that developed it the last ten years. - Easier integration of existing libraries, e.g. augeas, since we still have to implement new features. Right now we start to implement btrfs based snapshots where we will have a C++ library for the basic funcionality. - Make it easier for external contributions. ciao Arvin -- Arvin Schnell, <aschnell@suse.de> Senior Software Engineer, Research & Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Hi all,

This is from someone that would like to contribute, but soon gave up
when being faced with yet anoter language.

2011/1/31 Klaus Kaempf <kkaempf@suse.de>:
>> > Which goals would you achieve by implementing these ideas ?
>>
>> From the company point of view I see these goal:

For Novell as a company, to maintain the competance in YCP must be a
loss. Using standard languages would make it possible to resue the
competence in other projects.
This would also of course make it much easier to get new employees up
and running and to receive contributions fro a larger community.

Also if the new language is selected according to what other
distribution uses, then reuse between projects is a much better
option.

I love the way Yast works for me as a user, and I would hate to see it
slowly go down the drain. I know RedHat/Fedora uses a lot of Python
but have no clue what Debian/Ubuntu uses.

My personal preferences would be to use Python/Qt for the most part
:-) . Please consider the portability to smaller platforms when going
forward, to only make it a server/desktop tool would be a pitty at
this stage.


>
>>
>> - Easier integration of existing libraries, e.g. augeas, since we
>>   still have to implement new features. Right now we start to
>>   implement btrfs based snapshots where we will have a C++

>> - Make it easier for external contributions.
>
> Where do external contributors currently struggle ? Is it YCP ? Is it
> lack of documentation ? What else ?

>From my point:
- YCP is a no go
- a consistent  description of toolset, architecture and a getting
started "guide"

If a migration is decided, willit be possible to have a core set of
modules in the new system and keep the rest in the old?


Kind regards

Birger
-- 
To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org
For additional commands, e-mail: yast-devel+help@opensuse.org

On Monday 31 January 2011 11:10:55 Thomas Goettlicher wrote:

On Friday, January 28, 2011 04:50:10 pm Arvin Schnell wrote:

...

So what seems desirable and feasible? Some ideas:

1) Replace YCP with some common language? With more that 100

modules this looks impossible.

2) Allow a common language next to YCP? A good integration seems

difficult.

3) Improve YCP (at least fix bugs)? Do we want that?

4) Better bindings of C/C++ libraries for YCP?

Other suggestion?

Replacing all YCP code at once seems to be impossible. If we want to offer a new language for YaST we should choose _one_ and then stick to it. New modules can be written in this new language and old modules can be ported one by one if needed and when time permits.

In the past, we have made attempts with various languages. We have enhanced the infrastructure so that it should allow a python-only module (take Python as an example here), we have made some prototypes, but from some reason I cannot remember a single non-YCP module which was finished. Maybe we should collect the issues found during these experiments, there can be easy solutions of them. To be honest, I see one point which makes the transition hard: YCP was a single-purpose programming language and once you speak it fluently, you can write new modules very quickly and effectively. Many of those of us who tried Perl value YCP's strong typing system, for example. I don't want to start a flame regarding this. It is not universal reason valid for everyone but matches opinion of a group of developers based on a real-life experience. That's why I'd like to have an overview of issues with Python, Ruby, etc., from a real experience, ideally based on a prototype YaST module, and see how to tackle them. Jiri

If we choose the way as described above, YCP will stay for a longer period and therefore it makes sense to fix major YCP bugs.

-- Regards, Jiri Srain YaST Team Leader --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain@suse.cz Lihovarska 1060/12 tel: +420 284 084 659 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

On Jan 31, 2011, at 3:10 AM, Thomas Goettlicher wrote:

If we want to offer a new language for YaST we should choose _one_ and then stick to it.

+1. -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

* Martin Vidner <mvidner@suse.cz> [Jan 31. 2011 18:22]:

On Mon, Jan 31, 2011 at 10:08:00AM -0700, Bart Whiteley wrote:

...

On Jan 31, 2011, at 3:10 AM, Thomas Goettlicher wrote:

...

If we want to offer a new language for YaST we should choose _one_ and then stick to it.

+1.

Yes. It will be difficult, because each of the obvious suspects has arguments in favor for it:

Perl is most used in existing YaST modules after YCP. Python is most popular with other distros for managing the system. (as Birger mentioned) Ruby is most used for new development in our department.

This decision should be left to the people who will actually work on YaST going forward. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

On Jan 31, 2011, at 5:03 AM, Josef Reidinger wrote:

...

- Use a couple of languages people know and like

Maintenance nightmare.... E.g. I don't have problem to maintain projects in different languages ( now RoR, perl and YCP), but if I am maintaner and someone leave or move to another team and need to start maintaining new module which is in new language I spend some time to learn it and it is not good idea to have weak knowleadge of many languages. I think we should choose one language ( it is not important if it is python, ruby, perl whatever), but we should stay with it as then it is easy to learn just how module work and not need to know how language work.

+1. -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

2011/2/9 Robert Schweikert <rschweikert@novell.com>:

OK, here is one proposal.

Uses Python with the idea that individual modules are implemented as Python packages. This would allow us to package each module separately in a straight forward fashion. Nice granularity which would also benefit integration with WebYaST.

This also follows the idea Klaus had about being domain specific (which I like). The domain specific functions are implemented in __init__.py and the details are hidden from the user. In this case (only rudimentary implementation) the storage of the information for an NFS share is hidden in the nfsShare object, while the user setting up a share via createShare() does not need to worry about these details.

import yast3.nfs_client yast3.nfs_client.createShare(.....)

Advantages: - Everything is in Python thus this meets the common language  criteria that appears to be emerging in the discussion - Implementation via Python packages provides granularity and easy  packaging, facilitates small "footprint" for integration with WebYaST - Domain specific interface allows us to be very expressive - Easy to use in setup scripts - It should be relatively easy to put a GUI on top of this while  maintaining MVC paradigm

...

ie: one group/pair/individual could present a "prototype" module done with lang X, tools Y, and show how a module would look like, what possibilities this bring etc. Another group/pair/individual could do the same using a different approach.

Or take it even further. Adopt either Ubuntu or Fedoras base and continue to work with other distros to maximize the effect of the open-source effort. Why reinvent when it can be built on an existing stable base? Also the openSUSE contributions would then benefit a larger audience. (This is by NO means meant as a flame bait!) The only reason for not adopting an existing base would be branding. I can see that openSUSE might get to similar in regards to marketing. But for open-source I think it would be beneficial. The linux platforms that are progressing well today are the platforms where the platform i standardized. Kind regards Birger -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

On 02/09/2011 10:22 AM, Gabriele Mohr wrote:

Am 28.01.2011 16:50, schrieb Arvin Schnell:

...

Hi,

in a recent telco the question about the direction of the YaST architecture was raised.

I miss an important fact when reading the discussion here. For me it's not clearly pointed out how WebYaST and YaST will work together nicely in future. I think they should share as much code as possible, e.g. an interface which provides the logic for system access (something like Klaus has proposed?). I think it's a very important goal to bring WebYaST and YaST together and this aspect should be more respected in the discussion.

Yes. Agreed. I posted the information about technologies like COMAR exactly because that. -- Duncan Mac-Vicar P. - Novell® Making IT Work As One™ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

* Gabriele Mohr <gs@suse.de> [Feb 09. 2011 10:22]:

Am 28.01.2011 16:50, schrieb Arvin Schnell:

...

Hi,

in a recent telco the question about the direction of the YaST architecture was raised.

I miss an important fact when reading the discussion here. For me it's not clearly pointed out how WebYaST and YaST will work together nicely in future.

Thanks for bringing this up.

I think they should share as much code as possible, e.g. an interface which provides the logic for system access (something like Klaus has proposed?). I think it's a very important goal to bring WebYaST and YaST together and this aspect should be more respected in the discussion.

This reveals a key problem in the current discussion - treating YaST and WebYaST as separate projects. I believe this is wrong. What's needed is a common infrastructure/backend resp. API to do management tasks on a Linux system. This forms the low-level development API for the various user interfaces. What we currently know/discuss as 'YaST' would be the (rich) Qt user interface. What we currently know/discuss as 'WebYaST' would be the (limited) Web user interface. Additionally, a CLI interface for scripting is needed. All those user interfaces are using the common backend, exposing different details and functionality. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

* Thomas Goettlicher <thomas.goettlicher@suse.de> [Feb 10. 2011 11:11]:

On Thursday, February 10, 2011 10:13:10 am Klaus Kaempf wrote:

...

What's needed is a common infrastructure/backend resp. API to do management tasks on a Linux system.

I fully agree, especially because you wrote 'Linux system' instead of 'SuSE system'.

I did that on purpose ;-) Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

* Stanislav Visnovsky <visnov@suse.cz> [Feb 10. 2011 12:56]:

I'm loosing the sense of small steps, we are discussing grand unification plans again.

Even for small steps, you need a direction. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

On Thu, Feb 10, 2011 at 01:10:37PM +0100, Stanislav Višňovský wrote:

On štvrtok 10 Február 2011 13:05:06 Klaus Kaempf wrote:

...

* Stanislav Visnovsky <visnov@suse.cz> [Feb 10. 2011 12:56]:

...

I'm loosing the sense of small steps, we are discussing grand unification plans again.

Even for small steps, you need a direction.

Yes, it helps.

Still, tackling smaller steps is usually more feasible. One might argue though if 'dropping YCP' is a smaller step :-)

It's a leap :-) I intentionally limited my proposal just to the language switch, trying to postpone the architectural debate that ensued anyway. It will be tough enough to execute the switch as it is, without redesigning the framework along the way. -- Martin Vidner, YaST developer http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu

Robert, * Robert Schweikert <rschweikert@novell.com> [Feb 10. 2011 14:50]:

Without a clear picture of the architecture that everyone can work from you end up with something that is cobbled together and the pieces never fit properly.

thanks for the picture. If you replace "WebYaST" by "Web", then you will have me fully aligned ;-) Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

On Thursday, February 10, 2011 02:50:46 pm Robert Schweikert wrote:

Without a clear picture of the architecture that everyone can work from you end up with something that is cobbled together and the pieces never fit properly.

The implementation steps should be on the smallish side, no question. But there ought to be a big picture showing the "macro architecture" if you will, maybe something like the attached diagram.

The everyone can work on their own little piece of the world but with the big picture in mind. That way things will fit together. Having something like this ought to make it easier to make decisions about the moving parts.

Robert

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 | +--------------------------------------------------------------+ Perhaps rest service should sit on top of yast modules. Thomas -- Thomas Goettlicher SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Dne čtvrtek 10 Únor 2011 15:29:47 Klaus Kaempf napsal(a):

* Thomas Goettlicher <thomas.goettlicher@suse.de> [Feb 10. 2011 15:22]:

...

Your attached diagram looks similar to the overview designed by jdsn and me: Not quite.

...

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

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

Yes.

But it is there now. And the result is, webYaST brings huge amount of packages because of YaST. Jiri -- Jiri Suchomel SUSE LINUX, s.r.o. e-mail: jsuchome@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Praha 9, Czech Republic http://www.suse.cz -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Klaus Kaempf write:

* Jiri Suchomel <jsuchome@suse.cz> [Feb 10. 2011 15:37]:

...

But it is there now. And the result is, webYaST brings huge amount of packages because of YaST.

Yes :-( Thats why we have to move away from static languages like YCP to dynamic ones like Python or Ruby. Then a failing 'import' can be handled gracefully and package dependencies are drastically reduced.

It looks like new mantra called "dynamic languages". I am not sure if you ever try to handle such situations. Of course it is possible, but then code become really messy and also horrible to maintain and test it.... consider module A which depends on module B,C,D,E ( e.g. storage, language, time, bootloader and software management) then consider that A has if B,D is installed and C,E missing....and consider all combination. It is nice theory, but maintenance looks horrible for me. Benefit of dynamic languages is that you can change behavior based on runtime information, but changing behavior due to miss of completely modules is really bad idea....I don't see much ruby project which expects X different modules and acts different (if it is not abstract layer over it ). Pepa -- Josef Reidinger Appliance Toolkit team maintainer of perl-Bootloader, yast2-bootloader and parts of webyast and SLMS -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

It looks like new mantra called "dynamic languages". I am not sure if you ever try to handle such situations. Of course it is possible, but

On 02/10/2011 03:55 PM, Josef Reidinger wrote: then code become really messy and also horrible to maintain and test it....

consider module A which depends on module B,C,D,E ( e.g. storage, language, time, bootloader and software management)

It is not about the language, it is about the design. In YaST, every module uses functionality of another module and links to it, instead of every module providing an implementation of a service. So a module needs to install a package, in YaST, it imports packager, which makes every module depend on libzypp. yast2 package is the kitchensync where all the rest goes. Draw it and you get a spaghetti. YaST should request "give a package installation implementation" and handle gracefully the fact that there is none. Which is a much higher level than catching a import error. -- Duncan Mac-Vicar P. - Novell® Making IT Work As One™ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Am Thu 10 Feb 2011 03:47:56 PM CET schrieb Klaus Kaempf <kkaempf@suse.de>:

* Jiri Suchomel <jsuchome@suse.cz> [Feb 10. 2011 15:37]:

...

But it is there now. And the result is, webYaST brings huge amount of packages because of YaST.

Yes :-( Thats why we have to move away from static languages like YCP to dynamic ones like Python or Ruby. Then a failing 'import' can be handled gracefully and package dependencies are drastically reduced.

Using 'dlopen' and 'dlsym' as the killer feature of dynamic languages is really not fair. Please be honest in promoting Ruby. There is IMO only 1 argument supporting usage of dynamic languages: Program can be inspected and changed while running in production. And this ^^^ is only useful for always running services. Erlang excels in this. But it is really not the use case of YaST. Garbage collection, simple syntax, working with collections or ability to express ideas clearly is not just domain of Duck Typed languages. OTOH good luck with establishing a stable interface in a Duck Typed language. This can only be done with lots of documentation, convention and tests. But it cannot be enforced or verified. Python solved interfaces with zope-interface, which allows the programmer to specify "how do the data look like". Duck Typing by itself doesn't need to be bad. Going all the way and being unable to describe data structures definitely is. Most importantly because data structure description is an important communication channel for programmers. Martin

Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)

-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

On 02/10/2011 09:25 AM, Thomas Goettlicher wrote:

On Thursday, February 10, 2011 02:50:46 pm Robert Schweikert wrote:

...

Without a clear picture of the architecture that everyone can work from you end up with something that is cobbled together and the pieces never fit properly.

The implementation steps should be on the smallish side, no question. But there ought to be a big picture showing the "macro architecture" if you will, maybe something like the attached diagram.

The everyone can work on their own little piece of the world but with the big picture in mind. That way things will fit together. Having something like this ought to make it easier to make decisions about the moving parts.

Robert

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

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? I suppose "lib shell" is the API for scripting? If yes, that would appear to be too close to the point where the rubber meets the road. IMHO we want scripting to occur on top of the YaST modules and ideally have the YaST modules setup such that they can be imported into whatever language we end up with. As shown in my implementation proposal in Python import yast3.NAME_THE_CONFIG_MODULE and then have the domain specific interfaces available as in yast3.ntp.setNtpServer(....) In short I see the introduction of the "common lib" as a very big difference in the architecture diagrams. Note that I am not saying that there is no code that may be shared between some or all YaST configuration modules. All I am saying is that there is probably no need for another level of indirection. Code common to some or all YaST modules (such as the modified file detection for example) can be shared if this common code is simply implemented as a module at the same level as all the other YaST configuration modules. Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Novell-IBM Software Integration Center LINUX Tech Lead rschweikert@novell.com rschweikert@ca.ibm.com 781-464-8147 Novell Making IT Work As One -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

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@novell.com rschweikert@ca.ibm.com 781-464-8147 Novell Making IT Work As One -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

On 02/10/2011 01:14 PM, J. Daniel Schmidt wrote:

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.

Exactly my point, as the implementer for the configuration module I am willing to write and maintain, I have to stick my stuff into the common lib. The ASCII art diagram does not allow me to interact with the system without going through common lib. If I have something that needs a config file but doesn't fit in with common lib I am screwed and have to find my own solution for a bunch of things that I shouldn't have to. Or I have to argue with a bunch of folks to accept my stuff into common lib. Neither is very appealing to me.

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

The implemented module provides the domain specific interface used by all clients, YaST (in QT, Gtk+, or whatever toolkit), WebYaST (or other Web UI), a CLI tool..... Nothing is lost. The module (notice the box in my diagram says "Configuration modules" not "YaST modules") hides the specifics of individual or multiple config files behind a domain specific generic interface network.setDomainname(....) network.setDefaultGateway(...) for example.

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

These goals are met.

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.

I agree with "use something that is light weight" and "people can use as they see fit". That is exactly why I think a common lib is not the approach we want to take. I have not yet seen a common lib that tries to span a very large set of requirements be light weight, see my STL example below.

(WebYaST may only present a subset of the configuration options that YaST coult offer.)

Yes, but yet in the ACSI art diagram WebYaST still would depend on the glob of the common library. Thus it would pick up the implementation of a ton of interfaces that WebYaST does not provide any access to through the web based interface. In the other proposal WebYaST or any other client can pick and choose from any modules in the "Configuration Modules" box. Only pulling in those interfaces and the given modules dependencies.

...

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?

No, I do not think we want a SUSE only solution, thus the importance of the language discussion in the other thread. As shown below my proposed architecture is not a SUSE only solution. Each module is distribution independent and can easily be picked up by any distribution that is interested.

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.

This just sounds to me as if the CL is one big blob (and it is drawn that way as well) where everyone just throws their stuff in. This would according to my understanding look something like this import commonconfig So now I just picked up the interfaces for fiddling with a disk as well as the network, nfs, ntp, users, runlevel, you name it. Or in other words, I just loaded a bunch of stuff I don't want. And since everything is one glob my API documentation is a mile long, a pretty good way to make me not read it. I guess an example of a common library would be the STL. <sarcasm>Well, because the common implementation works so well there's also libboost to cover all the stuff that the divine inventors of the STL either didn't think of or couldn't be bothered to implement. But wait, maybe it will be implemented in the future and then something will move from libboost to STL.</sarcasm> How pleasant is it to work with that? In contrast the dynamic languages, with a modular design. You get a set of base modules "for free" when you install the core implementation and you can pick up a gazillion modules on an as needed basis.

From my point of view this is more easy than the current mixture of UI elements and system calls within the same YCP file.

I am not proposing to keep YCP or the current arrangement. I am trying to highlight the differences in the ASCII art architecture proposal and the one I had sent prior to that. The heart of the difference appears to be a unified common library (ASCII art proposal) vs. a more modular approach.

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.

Nope, sorry I don't think you understand what I am advocating. The module I implement (backend that fiddles with the config files I want to control) is implemented in 1 and only 1 directory. The location of the parent directory and what else is in the parent directory is rather immaterial to my implementation. Should I decide that I want a UI (Toolkit based, Web, or CL) frontend for my module I once again implement this in a directory that is "controlled" by me, and again the parent directory and it's location is rather immaterial. Preferably there would be some sort of module I can import to provide common GUI elements and this module should know how to display in ncurses etc. so I as a module developer do not have to worry about this, but that's convenience infrastructure, and any given distribution can decide to implement and brand this or not.

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

Again, I don't think you follow what I am trying to express. The architecture I propose is nothing else, and again borrowing from python, than import yast3.firewall As a developer wanting to use the module I don't really care whether the module I just imported lives in site-packages, some YaST directory, or other. I don't even care if what I just imported is implemented in C/C++, Python, or whatever (although I think pretty much everyone is in agreement that we want to stick to one language here). All I worry about is the documented interface of the module I just imported. And if I choose to, I can even decide to disable functionality if the import failed (see my earlier post, other thread I think). In this use case I can be a developer that works on a Web based UI, a toolkit based UI, or a command line frontend. In either case I get a hold of the configuration functionality in the same way. Now if I look at it from the other side of the coin, i.e. as the developer of the firewall module, I can stick my implementation in a directory called firewall in the parent directory of choice. This is completely distribution independent. In SUSE the module (directory containing the implementation) might live inside a directory named yast3 and on Fedora it might live in a directory named fedora-config. All fedora-config has to have is an empty __init__.py (and there is probably something similar for Ruby, or whatever language we end up with). The configuration module I just implemented is distribution independent. As a module developer I can control distribution dependence in my module by looking for config files in the expected places per distro and I am not dependent on the devine intuition by someone implementing a grand unified common configuration library.

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

I guess the bottom line is that I do not believe a common lib can be all encompassing and will cover every configuration I might possibly come up with in the future. Once I hit something that the implementer of the common lib has not thought off I am screwed. Now I have to figure out how to get something into the common lib. You just lost me as a contributor. Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Novell-IBM Software Integration Center LINUX Tech Lead rschweikert@novell.com rschweikert@ca.ibm.com 781-464-8147 Novell Making IT Work As One -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

On Thursday 10 February 2011 21:17:03 Robert Schweikert wrote:

...

Nope. Its you, the developer of the configuration task.

Exactly my point, as the implementer for the configuration module I am willing to write and maintain, I have to stick my stuff into the common lib. The ASCII art diagram does not allow me to interact with the system without going through common lib.

The thing we called "common lib" _IS_ directly interacting with the system. Put everything that you need to interact with the system together in a (lets call it) plugin that gets part of the "common lib". Don't thinkt of "common lib" as a thing that someone else is maintaining and you should rely on him. It's us, YaST developers, who extend the "common lib" with new functions (yes, sure, they should be stable and persistent in order not to brake existing configuration modules). The only reason why we separated the CL and the thing we called "YaST modules" in the ASCII art was, to show the separation of the model and the view. This would allow to run the view with user privileges and better desktop integration if a desktop-specific tool decides to use the CL directly.

If I have something that needs a config file but doesn't fit in with common lib I am screwed

I don't see why any such thing should not fit in CL? The CL is _the_ place to put it.

The implemented module provides the domain specific interface used by all clients, YaST (in QT, Gtk+, or whatever toolkit), WebYaST (or other Web UI), a CLI tool.....

Nothing is lost. The module (notice the box in my diagram says "Configuration modules" not "YaST modules") hides the specifics of individual or multiple config files behind a domain specific generic interface

network.setDomainname(....) network.setDefaultGateway(...)

for example.

Ok, then I guess I misunderstood your initial description and just miss the separation of model and view in your original picture.

Yes, but yet in the ACSI art diagram WebYaST still would depend on the glob of the common library. Thus it would pick up the implementation of a ton of interfaces that WebYaST does not provide any access to through the web based interface.

We didn't say anything about how this is implemented.

In the other proposal WebYaST or any other client can pick and choose from any modules in the "Configuration Modules" box. Only pulling in those interfaces and the given modules dependencies.

That is exactly what Thomas and I meant. We just didn't draw many small boxes in the "common lib" box (it already took long enough to get the ASCII art formatted nicely ;) ).

This just sounds to me as if the CL is one big blob

No, we never said and never meant that. After all I think in this discussion we too much interpret the drawings of each other, seeing, expecting something that is not there. Sure, we even left out some parts in our pictures (because for us they were too much detail). For me the pictures are just a help to visualize something that I describe in words. The description for me is more important. So please lets rather focus on what we write next to the images and graphs than to compare them. And I can only repeat myself: I think we really want the same thing, we just call it differently. That's why it's good to have descriptions next to the pictures. 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

On Friday 11 February 2011 15:52:32 Robert Schweikert wrote:

With a good architecture diagram we should be able to [...] ^^^^ That's the point. Our ASCII art was just a plain copy of our offices white board (with a little cleaning up). The "common lib" was on the board called "SMC" in the first diagram and "SCM" in the second - but we knew what we were talking about. It was never meant to be perfect, just to have something to discuss about.

If we can achieve this, then it will be easy for contributors to get started.

Sure. In our current discussion its about what and how we want to change something, so we are in a much earlier phase here. I think that's why we did not invest too much for a perfect diagram that is just a base for a discussion and not developer documentation. 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

<snip>

...

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" :)

Hooray! I understand this! I want to have it simplified this way!

Why not have it simplified even more?

Why must the GUI code be separated from the "backend code"?

Because it is not good programming practice. - You want the GUI to be an observer only and represent data in a way that makes it easy on the user - Writing GUI code is sufficiently difficult/cumbersome w.r.t. layout interaction of widgets etc. that in the GUI code one should focus only on the presentation to the user and not about parsing or data model etc. - Mixing GUI code and backend code makes it much more difficult to use a module in a scripting environment - Mixing GUI code and backend code leads to unnecessary bloat in a non GUI environment - Separation of concerns, the backend is concerned with the data model, file parsing, API and more, while the GUI is concerned about making things look pretty. These are often conflicting in some ways. ..... Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Novell-IBM Software Integration Center LINUX Tech Lead rschweikert@novell.com rschweikert@ca.ibm.com 781-464-8147 Novell Making IT Work As One -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Johannes Meixner write:

Hello,

On Feb 11 09:21 Robert Schweikert wrote (excerpt):

...

...

Why must the GUI code be separated from the "backend code"?

Because it is not good programming practice.

This is a reason why it _should_ be spilt but it does not justify to exclude potential contributors from the very beginning who may only want to implement a quick-and-dirty first usable test-version to check if the YaST programming environment seems to provide what they are looking for.

Remember what I wrote: ----------------------------------------------------------------- ... first and foremost it must be easy for an individual contributor to make his first usable version of a setup tool for his specific setup task.

Later when he likes to enhace it, it is the right time for the brilliant design ... -----------------------------------------------------------------

I think that separation UI from backend is quite common unix way ( usually backend is represented by command line tool, which of course has it disadvantages, so now it is more common to move backend to library). For me this separation is something like must-have as backend need root, but frontend should not need it. For me as individual contributor is more important well defined and well documented API to use. ( no I don't agree that code is the best documentation ) With good API contributor know what he can use in his own UI module or if he want contribute alternative backend part ( like for different distribution or as porting to different platform ). Josef

Kind Regards Johannes Meixner

-- Josef Reidinger Appliance Toolkit team maintainer of perl-Bootloader, yast2-bootloader and parts of webyast and SLMS -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

On Thursday, February 10, 2011 05:36:00 pm Johannes Meixner wrote:

Hello,

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.

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

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

...

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

OK, one more for today, because I just cannot help myself ;) Attached is a revision of my original diagram incorporating some of the design style of the ASCII art above. Differences: - There is no lib common, the lib common layer of the ASCII art diagram is implemented by a modularized layer called "Configuration Modules". - There is no lib-shell. In the modularized approach a power user can import/use any module implemented in the "Configuration Modules" layer directly, no need for additional indirection. - No "yast modules" as in the ASCII art, I believe these are superfluous. Additional notes: - Policykit integration would just be another module in the "Configuration Modules" layer - Zypper integration could be a SUSE specific module in the "Configuration Modules" layer, other distros would implement their own package manager integration module (although the API of this module would have to specified and be consistent across distributions) - If asynchronous communication between the GUI elements and the "Configuration Modules" layer is needed some kind of IPC mechanism could sit between the GUI modules and the "Configuration Modules" layer. I do not believe this to be necessary and think the GUI modules can directly import/use modules from the "Configuration Modules" layer. Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Novell-IBM Software Integration Center LINUX Tech Lead rschweikert@novell.com rschweikert@ca.ibm.com 781-464-8147 Novell Making IT Work As One

On Friday, February 11, 2011 11:07:37 am Johannes Meixner wrote:

Hello,

On Feb 10 17:21 Robert Schweikert wrote (excerpt):

...

Attached is a revision of my original diagram incorporating some of the design style of the ASCII art above.

You lost me. I do no longer understand it. I would not even try to use such an overcomplicated framework. As a module developer you don't need to understand the whole framework.

If you want to replace a car's headlamp bulb you don't have read the whole circuit diagram. Yes, the design of the car is complex but maintenance is easy. We should design YaST in a similar way. Adding a new module e.g. flux capacitor configuration _must_ be easy! It's very important that you remind not to lose focus on an easy extendable yast. Thank you.

By the way: Of course as an epmloyee of the same company who makes such stuff, I would have to use those stuff - but I would not try to use it if I was a free software contributor.

Kind Regards Johannes Meixner

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

On Friday, February 11, 2011 12:18:12 pm Johannes Meixner wrote:

Hello,

On Feb 11 11:39 Thomas Goettlicher wrote (excerpt):

...

We should design YaST in a similar way. Adding a new module e.g. flux capacitor configuration _must_ be easy!

As an example assume there is a software which provides a horrible stack of any kind of scripts to install it plus any kind of GUI programs to configure it.

Aassume that for this software plain "rpm" is insufficient to install it (e.g. assume this software needs a special kind of activation or authentication by its end-user).

Now a single user of this software (not the developer team of this software - but perhaps an user who provides this software "as is" via the openSUSE build service) likes to contribute a YaST module to install and configure this software.

What he wants to implement is a YaST module which provides a frontend that asks for particular installation parameters and calls each of the scripts one by one to get it installed and then the YaST module runs the software's GUI programs which configure the software.

Would it be easy to implement such a YaST module?

I hope I understood your use case correctly. Please correct me if I'm wrong. You have some shell scripts that need be be called with parameters and the return code indicates if everything went fine. You create a plugin for the commonlib or in Robert's notation a "configuration module" that abstracts these shell scripts. Let's say this module provides an api function bool flux::first_time_installation(parameter) it calls your shell script and returns its exit value. The whole business logic is implemented now. If you don't add anything else your yast offers automatically a configuration module for flux that shows an input field for first_time_installation(). You can test whether your business logic works. That's a poor ui and you want to improve it. Your next step is to polish the ui and replace the automatically generated ui module with your code that represents your workflow.

Basically such a YaST module would have a simple straightfoward workflow where YaST GUI dialogs which ask for particular installation parameters run intermixed with code which changes the system (the scripts and the software's GUI programs).

I would be more than happy if it was possible to implement such a YaST module in a single YaST source code file like: ------------------------------------------------------------------ import basic yast stuff import yast gui elements import run external non-gui programs import run external gui programs

repeat { show dialog which asks for parameters for first script } until check of parameters for first script is o.k.

run first script

if first script results failure then show error popup and exit 1

...

repeat { show dialog which asks for parameters for last script } until check of parameters for last script is o.k.

run last script

if last script results failure then show error popup and exit 1

show popup that installation is completed

show feedback that first GUI program is launched

run first GUI program

close feedback that first GUI program is launched

if first GUI program results failure then show error popup and exit 1

...

show feedback that last GUI program is launched

run last GUI program

close feedback that last GUI program is launched

if last GUI program results failure then show error popup and exit 1

show popup that configuration is completed

exit 0 ------------------------------------------------------------------

Kind Regards Johannes Meixner

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

On Friday, February 11, 2011 03:06:00 pm Johannes Meixner wrote:

Hello,

On Feb 11 13:12 Thomas Goettlicher wrote (excerpt):

...

On Friday, February 11, 2011 12:18:12 pm Johannes Meixner wrote: ...

...

...

As an example assume there is a software which provides a horrible stack of any kind of scripts to install it plus any kind of GUI programs to configure it.

...

...

...

What he wants to implement is a YaST module which provides a frontend that asks for particular installation parameters and calls each of the scripts one by one to get it installed and then the YaST module runs the software's GUI programs which configure the software.

Would it be easy to implement such a YaST module?

I hope I understood your use case correctly. Please correct me if I'm wrong.

What about when a software's graphical GUI programs have to be called from within a YaST module? That's where design clashes with reality. In this scenario you need to run the yast ui as user root. But more important: How to tunnel a gui program to a webyast module? From the design point you don't want this. Your example shows that reality looks different. :-(

For a real-world example:

In the YaST printer and scanner modules I provide that the user can run HP's own graphical GUI setup program "hp-setup".

HP's own tool "hp-setup" provides the only way to set up HP all-in-one devices which require a proprietary plugin downloaded from HP and installed on the end-user's machine after the end-user confirmed a particular license agreement.

Additionally "hp-setup" provides the best available support to set up HP all-in-one network devices.

I have neither the knowledge to deal with special cases for HP devices nor do I have the time to re-implement in YCP what "hp-setup" already provides "out-of-the-box" nor am I legally allowed to implement something on my own which deals with HP's proprietary stuff.

...

You have some shell scripts that need be be called with parameters and the return code indicates if everything went fine. You create a plugin for the commonlib or in Robert's notation a "configuration module" that abstracts these shell scripts. Let's say this module provides an api function bool flux::first_time_installation(parameter) it calls your shell script and returns its exit value.

Why do I need to implement a wrapper function? Does the commonlib not provide a ready-to-use module You split your code into two parts: business logic and user interface. In your specific case business logic is pretty simple as it just calls shell scripts. The ui doesn't even know that shell scripts are called it just the api's high level functions.

which I could import and use like in my example code:

...

...

------------------------------------------------------------------

...

...

...

import run external non-gui programs

...

...

...

run first script

or does the commonlib not provide a ready-to-use function like in YCP "SCR::Execute(.target.bash_output, bash_commandline)"?

The commonlib provides such a function but it's not directly used by ui modules, because running shell scripts isn't an abstract task.

Kind Regards Johannes Meixner

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

On 02/11/2011 05:39 AM, Thomas Goettlicher wrote:

On Friday, February 11, 2011 11:07:37 am Johannes Meixner wrote:

...

Hello,

On Feb 10 17:21 Robert Schweikert wrote (excerpt):

...

Attached is a revision of my original diagram incorporating some of the design style of the ASCII art above.

You lost me. I do no longer understand it. I would not even try to use such an overcomplicated framework. As a module developer you don't need to understand the whole framework.

I somewhat disagree with this. As a module developer you must understand the basic concepts and the big picture of the framework. If you don't you develop in a vacuum. One does necessarily need to understand every intricate detail of the framework, that is correct. Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Novell-IBM Software Integration Center LINUX Tech Lead rschweikert@novell.com rschweikert@ca.ibm.com 781-464-8147 Novell Making IT Work As One -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

On 02/11/2011 05:07 AM, Johannes Meixner wrote:

Hello,

On Feb 10 17:21 Robert Schweikert wrote (excerpt):

...

Attached is a revision of my original diagram incorporating some of the design style of the ASCII art above.

You lost me.

Sorry, why? Please explain what elements of the revised diagram throw you for a loop. rev2 is in principle the same as the original.

I do no longer understand it. I would not even try to use such an overcomplicated framework.

What part do you see as overcomplicated? If we want to have an architecture everyone can work to and with the pictorial representation needs to be easy to grasp for pretty much everyone. How about the attached diagram? Thanks, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Novell-IBM Software Integration Center LINUX Tech Lead rschweikert@novell.com rschweikert@ca.ibm.com 781-464-8147 Novell Making IT Work As One

On 02/11/2011 10:24 AM, Klaus Kaempf wrote:

* Robert Schweikert <rschweikert@novell.com> [Feb 11. 2011 16:17]:

...

How about the attached diagram?

Ok from the general concept, but problematic in two details

- REST is separate from the API of other UIs

Not really, I am trying to express that we need to have some service that makes the API of the modules in the "Configuration Modules" layer available. The API itself should still be the same, issue GET or POST GET (network.getHostname) POST (network.setDomainname) vs. the other user interfaces import yast3.network yast3.network.getHostname() yast3.network.setHostname() But it may not be this simple, not a web developer ;)

- Maintaining a distinct UI-lib plus Qt and Ncurses besides the Web UI will need a lot of resources. Not alone coding but esp. from a design point of view.

Well I think UI-lib should really be responsible rendering to GNOME, KDE, ncurses. The pictorial representation is not good, will think about how to improve it. I think we should target something like the following pseudo code: myConfigGui.extension import yast3.myConfigBackend import yast3.gui_elements text = yast3.gui_elements.text_box() The gui_elements module takes care of QT vs. Gtk+ vs. ncurses, of course that is not cheap as far as effort is concerned. Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Novell-IBM Software Integration Center LINUX Tech Lead rschweikert@novell.com rschweikert@ca.ibm.com 781-464-8147 Novell Making IT Work As One -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

On 02/11/2011 10:43 AM, Johannes Meixner wrote:

Hello,

On Feb 11 10:17 Robert Schweikert wrote (excerpt):

...

On 02/11/2011 05:07 AM, Johannes Meixner wrote:

...

You lost me.

Sorry, why? Please explain what elements of the revised diagram throw you for a loop. rev2 is in principle the same as the original.

I cannot because to explain something, one has to understand it.

I asked you to explain what you didn't understand ;)

...

How about the attached diagram?

Much better.

What I think what it means is that I need only to care about the green part (i.e. make a configuration module).

Yes.

The rest seems to only show me the environment and I don't need to care about the various kind of user frontends. They are there and all of them "just work".

Yes, but if you want to have a module that others can interact with via the command line or a GUI you will have to implement that behavior. There is no "automagic generate my UI code" engine.

Of course if I may find out later that I would have to care about the various user frontends,

Only the user front ends you deem important to support. However, since things are nicely separated someone else who really likes to implement GUIs can easily put a frontend on top of you module. Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Novell-IBM Software Integration Center LINUX Tech Lead rschweikert@novell.com rschweikert@ca.ibm.com 781-464-8147 Novell Making IT Work As One -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Hi, On 02/11/2011 05:24 AM, J. Daniel Schmidt wrote:

On Thursday 10 February 2011 23:21:17 Robert Schweikert wrote:

...

Attached is a revision of my original diagram incorporating some of the design style of the ASCII art above.

Differences:

- There is no lib common, the lib common layer of the ASCII art diagram is implemented by a modularized layer called "Configuration Modules".

You only gave it another name. I never said that the thing Thomas an I called "common lib" should be one blob, that any module has to load even if does not need it.

Correct, but using "lib" as a name implies that this is one piece. A library on the system is in one piece, you cannot load half of libc. <snip>

Reading your comments I really think that we basically meant the same,

Yes, I think we are pretty much on the same page. That's why I attempted to somewhat merge the two presentations of the architecture diagram. And it appears that I have succeeded. Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Novell-IBM Software Integration Center LINUX Tech Lead rschweikert@novell.com rschweikert@ca.ibm.com 781-464-8147 Novell Making IT Work As One -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

On 02/10/2011 06:34 PM, J. Daniel Schmidt wrote:

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.

This is fine, but to design a good API you need to start with the module/client itself, and iterate the APIs as you go. There is no such thing as a useful API designed on paper. -- Duncan Mac-Vicar P. - Novell® Making IT Work As One™ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org