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