Mailinglist Archive: yast-devel (177 mails)

< Previous Next >
Re: [yast-devel] A Plan for YaST: Project Amaranth
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@xxxxxxx
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@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >