A draft for a standard for desktop configuration

[Philip Van Hoof]

On Tue, 2005-09-13 at 00:26 +0100, Dave Cridland wrote:

> Doesn't matter - it's the apps that either handle the data or don't. 
> Seems fair to let them decide what's legal and what's not. That's not 
> to say that schemas are wrong, just that the enforcement of them is 
> both futile and a waste of resources. After all, 99% of the time, 
> it's the application that put the data there in the first place. If 
> it can't understand what it wrote, my bet is that it's ever so 
> slightly buggy. :-)

Ok, breaks!

This discussion is going to be about the specification, not about how a
potential infrastructure should be implemented. The implementation is
interesting but shouldn't be discussed here.

Else I formally regret that I posted this on XDG-list. And will shut up
and disregard everything that is going to be discussed here.

Luckily are most reactions very positive and constructive. I fear that
this specific tree/thread is going the wrong way.

Last time lengthy discussions about this happened here, I lost my
interest in trying to discuss it here. A lot people on this mailing list
are not capable of doing that discussion.

My final word on this


First I'll repeat "the features" in the document.

o. The following basic types: int, string, Boolean, double
o. Non homogeneous or mixed lists with instances using the basic types
   and again lists (recursive types with a depth limit of 32 levels of
   recursion)
o. A standardised root namespace specification
o. A standard way of defining the path to a setting (defining the key)
o. The possibility to define combined types or structures using non
   homogeneous lists
o. Support for type enforcement for a specific setting using schemas
o. Support for a default value for a specific setting using schemas
o. Support for a localised long and short description for a specific
   setting using schemas
o. Usage of the D-BUS inter process communication system
o. Notification when specified keys change

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

o. It means that the system has installed defaults (as defined by the
   programmer)

o. It means that each key can be documented (by the programmer and
   translators)

Why? 

There's many reasons including data integrity, security and consistency.

A possible daemon implementation (this is "not" an enforcement by the
specification, it's a "suggested" or "proposed" implementation
technique):

o. Keep a hashtable with key versus d-bus signatures (the d-bus
   signatures are in the schemas, they can be parsed once and only the
   d-bus signatures have to be stored in the memory of the daemon).

   Validation can happen at the highest level: During the D-BUS protocol
   communication with the clients. Simply because for each key you
   "know" what signature the client "has" to use. This is the purpose of
   the "dbus" attribute of the "type" node.

o. Do high-level schema checking in a high-level library like the
   library of KConfig or libgconf or libdconf or whatever. For example
   check for your self-defined complex/combined types (like color and
   rect types).

o. I'm not sure where validation of the <min/> and <max/> should take
   place. For numeric values I'd say they should happen in the daemon
   also.

> They're great for when you want to hit GConfTool et al, of course, 
> but the only reason I can honestly think of for enforcing validation 
> in the system is as a nanny-method of trying to encforce that they 
> exist.


[CUT]

> I have to say I'm unaware of any existing configuration system that 
> does do anything other than application-level validation - the 
> argument that validation is vital is therefore a little weak to me.

OpenOffice.org and GConf both have schema validation. GConf has schema
validation in it's daemon (but it could/should be implemented in the
library, indeed).

The reason why GConf can do it's fully in it's library is simply because
not a single application talks to the daemon directly (for example by
talking with it using ORBit-2). All applications use libgconf.

This specification doesn't yet talk about any libconfigure or
libwhatever. The specification doesn't specify the use of a high level
library and perhaps will there be desktop applications that won't use a
trusted library. 

So this is a different situation. Please keep this in mind.


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