On Wednesday 09 February 2011 22:56:45 Duncan Mac-Vicar P. wrote:

On 02/09/2011 03:05 PM, Martin Vidner wrote:

...

Take the existing unfinished attempts yast2-ruby-bindings,

yast2-libyui, ruby-yui, bind libstorage to ruby.

- loudly state the intent to make them usable, including a timeline (see When) - provide good and up-to-date documentation - integrate with the Ruby ecosystem: -- document in form usual for Ruby developers (rdoc/yard) -- get found at rubygems (if only as a stub to point to the real package) - move from Subversion to Git (host at Gitorious, Github, or both) (see Why Git) - give good examples of usage, by converting a couple of production

YaST modules to the new platform

Hey Martin, this is a great start.

While I have to admit I am biased because I love ruby, There are other reasons:

- We have done already a lot of ruby investments in the team. - Rails is great to have. WebYaST

The plan looks great. Just some comments:

- May be separate the ruby/UI part from the ruby/YCP bridges, that is, not access the UI using YCP but direct ruby bindings. Rethink how this API is exposed to the language. - Migrate/Document current use cases (y2log, y2doc, y2tools) with native ruby equivalents - Look at what will replace SCR. Look at COMAR. Good stuff.

I'd target higher here: D-Bus based interface can be only local, for WebYaST we have the REST API on top of D-Bus anyway, so why not use it? Using desktop YaST for managing machines remotely could be a nice bonus for rather low price (meaning added to what you plan to invest), you would not have to have the UI libraries installed on each system. I have one concern about D-Bus, probably coming from lack of knowledge: SCR is able to run an instance in chroot, which is used during installation; while I can imagine any kind of web service run in chroot as well, can D-Bus handle this? 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

2011/2/9 Martin Vidner :

A Plan for YaST: Project Amaranth =================================

Why ---

YaST as a platform has been stagnant for the past few years. Half of the original team has been busy with WebYaST and other web projects. Since relicensing to GPL in 2004 we got very few contributions - Benjiman's One Click Install being a notable exception - Oracle contacted us with their patches (based on a previous  version of SLE), but we did not follow up. Much of the code has no tests, patching it is risky. Linux around evolves, a recent example being systemd, so YaST must keep up. If we don't provide a direction for YaST, it will rot and die.

What ----

Amaranth is a project to open up YaST and realize its potential: Deprecate YCP, a custom YaST language, in favor of Ruby(*), a widespread one. Thus gain contributors from openSUSE and possibly other distro communities.

*) see a followup mail about the language choice

How ---

Take the existing unfinished attempts yast2-ruby-bindings, yast2-libyui, ruby-yui, bind libstorage to ruby.

- loudly state the intent to make them usable, including a timeline (see When) - provide good and up-to-date documentation - integrate with the Ruby ecosystem: -- document in form usual for Ruby developers (rdoc/yard) -- get found at rubygems (if only as a stub to point to the real package) - move from Subversion to Git (host at Gitorious, Github, or both) (see Why Git) - give good examples of usage, by converting a couple of production  YaST modules to the new platform

When ----

Have it all ready by the release of openSUSE 12.0 (November 2011) at the latest. Better, do it for an earlier milestone and have 12.0 feature independent contributions. Don't try hasty fixes for 11.4, now we still can't guarantee the API. Possibly do a backport.

Who ---

The long term goal is "hackers from around the Tux world". For now, it's myself, looking for you, the YaST hackers, to join, and for the team leads, project and product managers to give us time for it.

Why Git -------

Git enables fearless hacking, power to the people, easy merging.

Code Name ---------

Amaranth is a purple (read .py.rb.pl) flower whose name means 'unwithering'. The tool is still branded YaST. Amaranth is the project to make the transition to world domination.

Why is a separate project needed? Why not combine forces with already existing mature environments? Especially when a major change is to be done anyway? I think that it can be done faster and safer if the creative forces are combined in stead of duplicating existing work. Kind regards Birger -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

On Thursday, February 10, 2011 08:58:48 am Jiri Srain wrote:

On Wednesday 09 February 2011 22:56:45 Duncan Mac-Vicar P. wrote:

...

On 02/09/2011 03:05 PM, Martin Vidner wrote:

...

Take the existing unfinished attempts yast2-ruby-bindings,

yast2-libyui, ruby-yui, bind libstorage to ruby.

- loudly state the intent to make them usable, including a timeline (see When) - provide good and up-to-date documentation - integrate with the Ruby ecosystem: -- document in form usual for Ruby developers (rdoc/yard) -- get found at rubygems (if only as a stub to point to the real package) - move from Subversion to Git (host at Gitorious, Github, or both) (see Why Git) - give good examples of usage, by converting a couple of production

YaST modules to the new platform

Hey Martin, this is a great start.

While I have to admit I am biased because I love ruby, There are other reasons:

- We have done already a lot of ruby investments in the team. - Rails is great to have. WebYaST

The plan looks great. Just some comments:

- May be separate the ruby/UI part from the ruby/YCP bridges, that is, not access the UI using YCP but direct ruby bindings. Rethink how this API is exposed to the language. - Migrate/Document current use cases (y2log, y2doc, y2tools) with native ruby equivalents - Look at what will replace SCR. Look at COMAR. Good stuff.

I'd target higher here: D-Bus based interface can be only local, for WebYaST we have the REST API on top of D-Bus anyway, so why not use it? Using desktop YaST for managing machines remotely could be a nice bonus for rather low price (meaning added to what you plan to invest), you would not have to have the UI libraries installed on each system. I think there should be a common library for system access (e.g. COMAR). Both webyast backend and desktop yast link against it. Dunno if dbus is appropriate here. Doesn't every layer slow down interaction.

I have one concern about D-Bus, probably coming from lack of knowledge: SCR is able to run an instance in chroot, which is used during installation; while I can imagine any kind of web service run in chroot as well, can D-Bus handle this?

Jiri

-- 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 Thursday 10 February 2011 11:08:53 Thomas Goettlicher wrote:

On Thursday, February 10, 2011 08:58:48 am Jiri Srain wrote:

...

On Wednesday 09 February 2011 22:56:45 Duncan Mac-Vicar P. wrote:

...

On 02/09/2011 03:05 PM, Martin Vidner wrote:

...

Take the existing unfinished attempts yast2-ruby-bindings,

yast2-libyui, ruby-yui, bind libstorage to ruby.

- loudly state the intent to make them usable, including a timeline (see When) - provide good and up-to-date documentation - integrate with the Ruby ecosystem: -- document in form usual for Ruby developers (rdoc/yard) -- get found at rubygems (if only as a stub to point to the real package) - move from Subversion to Git (host at Gitorious, Github, or both) (see Why Git) - give good examples of usage, by converting a couple of production

YaST modules to the new platform

Hey Martin, this is a great start.

While I have to admit I am biased because I love ruby, There are other reasons:

- We have done already a lot of ruby investments in the team. - Rails is great to have. WebYaST

The plan looks great. Just some comments:

- May be separate the ruby/UI part from the ruby/YCP bridges, that is, not access the UI using YCP but direct ruby bindings. Rethink how this API is exposed to the language. - Migrate/Document current use cases (y2log, y2doc, y2tools) with native ruby equivalents - Look at what will replace SCR. Look at COMAR. Good stuff.

I'd target higher here: D-Bus based interface can be only local, for WebYaST we have the REST API on top of D-Bus anyway, so why not use it? Using desktop YaST for managing machines remotely could be a nice bonus for rather low price (meaning added to what you plan to invest), you would not have to have the UI libraries installed on each system.

I think there should be a common library for system access (e.g. COMAR). Both webyast backend and desktop yast link against it. Dunno if dbus is appropriate here. Doesn't every layer slow down interaction.

I'm not sure either. We need an interface because of two reasons: - have only the back-end runing as root - provide network transparency (to have the client - e.g. yastwc - run remotely) That was why I mentioned the REST API as a better solution. Regarding Klaus' comment from other reply on this email: I fully agree, we should definitely target more high level than what we have now. 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

On Thursday 10 February 2011 14:36:07 Jiri Suchomel wrote:

Dne čtvrtek 10 Únor 2011 11:28:08 Klaus Kaempf napsal(a):

...

* Jiri Srain [Feb 10. 2011 08:59]:

...

I'd target higher here: D-Bus based interface can be only local, for WebYaST we have the REST API on top of D-Bus anyway, so why not use it?

Thinking about it, I would propose to drop the WebYaST REST API as it is currently.

It is too low-level and should be replaced by a richer / more functional approach. It exposes YaSTs SCR layer, while it should expose the YaST 'module' layer.

This is not true, at least not generally. Current webYaST has tasks like - list all services - start/stop given service - add a user - read/write network settings - read/setup new LDAP configuration

These actually are high level tasks, and mostly are mapped to YaPI, which actually is YaST 'module' layer.

That's right, the question is what exactly YaPI offers. There is no generic answer, as a consequence of the way YaPI was designed in its beginnings. In many (NOT ALL) cases YaST modules just store parsed configuration files, which YaPI then exposes through the interface. In such cases it would be possible provide API on higher level than configuration file structured as XML or YCP structure (I may overexpress a bit). As I wrote, the above is not valid for every module. But it definitely is something worth looking into. 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