Mailinglist Archive: yast-devel (129 mails)

< Previous Next >
Re: [yast-devel] SCR usage statistics.
  • From: Klaus Kaempf <kkaempf@xxxxxxx>
  • Date: Mon, 19 Nov 2007 10:40:51 +0100
  • Message-id: <20071119094051.GA24444@xxxxxxxxxxxxx>
* Duncan Mac-Vicar P. <dmacvicar@xxxxxxx> [Nov 19. 2007 00:35]:

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.

If we agree to refine (redefine?!) our backend model, I strongly believe
the CIM model is the way to go. Maybe not all of it [*], but those parts
we pick from it must be 100% compatible with CIM.

[*] No, I do not know which parts to take and which to leave behind.
Thats what this discussion thread if for ;-)

[... nice Ruby approach removed for readability ...]

Note: the above example is even compatible with the old scr, as any path is
passed down to the old SCR.

Is 'compatibility with old SCR' a desirable property ? How much would
this please current developers ? How much would this scare new ones
away ?
Finding the balance between 'everything shiny and new' and 'keep it as
it is' is important.

What do others think ?

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

Being able to easily use existing (low level) libraries for system
access is very imporant from my POV.


Going back to SCR. I don't think the syntax sugar is very important, but how
we use existing knowledge there.

Given that we want to replace YCP with a object-oriented scripting
language, the syntactic sugar comes almost for free.

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.

Thats why we need a layer on top to shield the details of the model
implementation from yast module developers.

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

Using WBEM for local operations is not the way to go. Don't mix
problems of a WBEM implementation with the model aspects of CIM.

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

Given the right instrumentation, file access is rarely needed. Most
config files are covered by the model and provides objects for access.

Where (raw) file access is needed, it should follow the posix model
and abandon CIM (if its really that bad ;-))

The 'scr statistics' posted before should give a hint if and where file
access is needed.

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! :-)

I'd like to look into a nice and useful backend api (replacing SCR)
first and try different transports:
1. instsys system, directly using libraries (resp. cim providers)
2. policy kit system, with separation of rights
3. distributed system, ws-man transport to remote client

The transport is completely transparent at the api level.

SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG N├╝rnberg)

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

< Previous Next >