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

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

* 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. The SCR layer handles 'disks', 'shell commands' and 'config files'. Installing a new disk requires detection ('disk'), partitioning ('shell'), formatting ('shell'), mount point creation ('shell'), mounting ('shell') and editing the fstab ('config'). On the module layer, installing a new disk would be a single REST call. The example might not be typical, but you get the idea. 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 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

On Wednesday, February 09, 2011 10:56:45 pm 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. Which alternatives to COMAR are available? COMAR is used by pardus only right now. In a perfect world we use stuff that's popular and (web)yast is aviable for all distros.

Duncan

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