Mailinglist Archive: yast-devel (129 mails)

< Previous Next >
Re: [yast-devel] Fwd: discussion about YaST infrastructure and foundation
  • From: "Benji Weber" <>
  • Date: Thu, 8 Nov 2007 15:36:24 +0000
  • Message-id: <d6b310ce0711080736m5e258ec9t4a8e247ee69ee153@xxxxxxxxxxxxxx>

Interesting discussion.

IMO multiple language support is probably one of the least significant
of problems with the YaST platform from a developer point of view, in
fact it might be part of the problem.

The main things YaST platform does offer developers at the moment are perhaps

* Library for toolkit independent UIs using native widgets on each.
* Library for reading and writing system configuration.

And the main disadvantages are perhaps

* Difficult to use other non-yast libraries - end up either calling
random SCR agents, hacking things together using perl libraries,
pkg-bindings style things etc.
* You can't easily re-use functionality in YaST from other apps.
* YCP not object oriented - also means that APIs consumable from YCP
have to be non-OO which is quite limiting.
* UI still too tightly coupled to management - UI has to run as root too etc.
* Slow.

And lots more.

I see the problem as less people wanting to develop in their favourite
language, - language syntax & semantics aren't very hard to learn if
there's an incentive. However, people are now used to developing on a
platform with very extensive libraries like java, .net, even python
etc. YaST does not make it easy to utilise anything that's not YaST.

Whereas on most platforms one would simply pick a library to do
something - say parse an XML config file, in YaST one has to mess
around working out how to do it, and deal with the mess of lists of
maps of lists that ensues. It's not very productive.

All of these problems are really down to YaST being its own platform,
rather than specialised libraries as part of a larger platform. This
probably made sense and was an advantage 8 years ago when there was no
Free java, and no mono.

I think the third strategy of migrating things to JVM/CLR is the bset
out of those suggested.

If you were developing YaST today instead of a decade ago would you
really not choose to make it part of a platform like java which is

* very fast
* extensive libraries
* largest developer base
* has hundreds of languages targeting it.

Benjamin Weber
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups