Mailinglist Archive: yast-devel (129 mails)

< Previous Next >
Re: [yast-devel] SCR usage statistics.
  • From: "Duncan Mac-Vicar P." <dmacvicar@xxxxxxx>
  • Date: Mon, 19 Nov 2007 00:42:09 +0100
  • Message-id: <200711190042.10384.dmacvicar@xxxxxxx>

I agree with Klaus here, one thing is about the CIM and WBEM tools and the
other is reinventing our own model.
The CIM model is quite complete, and we should try to come up with something
following its philosophy.

About SCR, yes, creating agents is not something intuitive, specially if it is
not a simple inherited ini file agent, but a full YaST component.

After all the interesting we discussed with Klaus during the week, I have been
thinking a lot into all those problems, and started looking for solutions.

For example, playing with a little of Ruby sugar, I managed to replicate SCR
in a interesting way:

Lets see how do I define an agent:

Plugin.define "release_agent" do
author "Duncan"
version "1.0.0"
extends :agent
run_before :other

def read(path)
if path == :'.system.product.edition'
f ='/etc/SuSE-release', 'r')
f.each_line do |l|
return l
return ""

def supports_path?(path)
return path == :'.system.product.edition'

puts SCR::read(:'.system.product.edition')

done. Why is it so hard with our tools, because we reinvented everything.
(Note, the example implementation of a SCR engine is 26 lines of code, not
shown above)

Note: the above example is even compatible with the old scr, as any path is
passed down to the old SCR. Require the wbem module and you can add wbem
access, require drb and you can call distributed code.

Now, our main problem is that we have to interact with quite a lot of code in
different languages, ages, paradigms. We have our own component model, but it
is quite complex. We could go our way and implement all the YaST basic core
in Ruby or Python and add nice stuff like WBEM access, access to services in
the web, etc, but we need a nice way to reuse and use functionality from
C/C++ code, Python, Perl, etc, and the other way around. Especially if we are
dealing with the system, you don't want the developers to learn how to create
ruby extensions or python modules just to interface with some low level
library. We depend or will depend on that (if we plan to ditch everything
inhouse that is a reinvention).

We have that component model right now (liby2) but try to create a component
yourself, isn't that the reason why libstorage uses generated perl swig
bindings, to interact to the component model via the super complex

I was giving a look at solutions out there. One I found was
OASIS Service Component Architecture / C and C++ (SCA-C-C++) which has a
implementation by Apache called Tuscany, already in the 1.0 Milestone3.
Its a service model, more oriented to web services but supporting local
components. The approach is pretty simple, a service in c++ is just a .h
defining the interface, the implementation, and a wsdl file. You can
implement them in python and ruby (services and clients) and that is
supported by the runtime out of the box. There is an article at IBM
DeveloperWorks [1].

Going back to SCR. I don't think the syntax sugar is very important, but how
we use existing knowledge there. The CIM model is a place to start, but there
are also issues that are not intuitive. The CIM model is just a OO way of
looking the system, where you ask for instances of a class, and then use the
objects properties and methods.
If you ask the CIMOM for the instances of CIM_UnixFile, you get the root
tree /, in my experiments, I had no clue how to go forward and do _SIMPLE_
stuff like reading, globing, etc. (not to mention it took 10 seconds to read
10 directories in / but probably it was ruby::wbem fault).
However, stuff like getting the numbers of CPU, the installed products, etc.
CIM provides a model much more consistent than the low level greps of /proc
and the package bindings, but some models like accessing files are not nice.
(An argument could be that we should not access files, but I am not sure
about that).

The big question when prototyping all the ideas floating out there is, how to
move on. Now there is some momentum, and the right time for other pieces (for
example, the great YaST UI being decoupled).

If anyone has a concrete experiment to try next, speak on! :-)


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

< Previous Next >
Follow Ups