A draft for a standard for desktop configuration

[Philip Van Hoof]

On Tue, 2005-09-13 at 11:02 +0200, Waldo Bastian wrote:
> On Tuesday 13 September 2005 10:01, Philip Van Hoof wrote:
> > This basically means that the infrastructure is responsible for schema
> > enforcement.
> >
> > What does that mean?
> >
> > o. It means that a desktop application, no matter how badly programmed,
> >    can't cause a key to be written as a type other than the one
> >    specified in the schema.
> >
> > o. It means that only the developer of the application (the installation
> >    program or script) decided about that type.
> >
> > o. It means that any invalid "setting a key" attempt fails
> 
> The current proposal fails to meet these objectives at the moment because the 
> typing is not complete. Only low level DBUS types are somewhat sufficiently 
> defined, but not the higher level types such as "font" or "color".

More or less correct, however. The library writer (which for KConfig,
would probably be you :p) can however decide about the high level type
and about the d-bus signature for it. A daemon would be responsible for
checking that d-bus signature. Making it type-safe (since the d-bus
signature makes sure the high-level type can use the data coming from
the daemon).

Note that this is a proposed/suggested implementation technique for a
daemon. It's not enforced by the specification. The specification
enforces only what it has to enforces.

So the signature tells the daemon's backend what it should store. 

For example:

The high level library developer creates a new type "color" in a schema.
It has the d-bus signature "iii" (three ints for Red, Green and Blue)
and the name "color". The min/max for each of the values is 0-255.

The schema-related responsibilities:

The daemon ...

o. is responsible for checking that the type is a "iii" where each "i"
   is between 0 and 255. For that it can keep a minimal hashkey with a
   key and (the d-bus signature, min and max) instance.

o. if it's an "iii" where each "i" is between 0 and 255, it's
   responsible for storing the key/value pair using it's backend.

o. when reading from the backend, it's responsible for checking that the
   backend is (still) consistent with the d-bus signature.


The high level library ...

o. is responsible for checking that the type is "a valid color". This
   checks whether the desktop developer has created the instance
   correctly. For "a color" this is rather simple (three unsigned
   chars).

o. is responsible for giving a default value if the daemon doesn't have
   a value

o. is responsible for giving the description in the current locale.
   Applications like a administrator tool will ask for this.


-- 
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
http://www.pvanhoof.be - http://www.x-tend.be