A draft for a standard for desktop configuration
Philip Van Hoof
spam at pvanhoof.be
Tue Sep 13 11:01:16 EEST 2005
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. :-)
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
o. A standardised root namespace speciﬁcation
o. A standard way of deﬁning the path to a setting (deﬁning the key)
o. The possibility to deﬁne combined types or structures using non
o. Support for type enforcement for a speciﬁc setting using schemas
o. Support for a default value for a speciﬁc setting using schemas
o. Support for a localised long and short description for a speciﬁc
setting using schemas
o. Usage of the D-BUS inter process communication system
o. Notiﬁcation when speciﬁed keys change
This basically means that the infrastructure is responsible for schema
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
o. It means that each key can be documented (by the programmer and
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
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
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
> 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
> 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
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
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
More information about the xdg