A draft for a standard for desktop configuration

[Philip Van Hoof]

On Tue, 2005-09-13 at 11:20 +0200, Philip Van Hoof wrote:


IMPORTANT!

I wrote this:

> 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 I never said that the specification enforces you to implement the
schema validation in the daemon. 

What is enforced by the (current) specification is that your infras-
tructure needs to validate the type of the values.

So let's say your library has high level get and set functions like

"value = get ("/org/hello/pref")" and "set ("/org/hello/pref", value)"
then the only thing that the current specification enforces is that the
get will always return the type as specified in the schema, and the set
will only accept value to be the type as specified in the schema.

How you implement that (in your library or in the daemon and backend)
isn't specified in the current specification. And my previous E-mail is
just a suggested implementation technique (it's not a specification as
specified in the current specification, it's a suggestion of mine).

I repeat this because one person replied me personally with a rather
angry e-mail where he tried to again explain me why it's a bad idea to
do schema enforcement in the daemon.

Please understand that this isn't the focus at this moment. The focus is
about creating an XML schema (using DTD or XDG or whatever). That is
important at this moment.

Where to do the schema enforcement is, at this moment, an implementation
detail.


> 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