A draft for a standard for desktop configuration

[Philip Van Hoof]

Hey Waldo,

Thanks for your comments/suggestions.

I'm going to look at them tomorrow. Else chances are high that I spend
the entire night fixing things :p. Which isn't a good idea if you, like
me, have to go to work tomorrow :-).

You are, of course, invited to make adaptations and send me diffs and/or
if you need an account on my repository, feel free to ask.

I'll quick-reply inline ..

On Mon, 2005-09-12 at 23:26 +0200, Waldo Bastian wrote:

> Comments for section 5.2:
> 
> Please use $XDG_DATA_DIRS/configuration as defined by
> http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html#referencing
> instead of hardcoding /usr/share/configuration

Ok/Oeps :)


> Comments for section 5.3:
> 
> KConfig supports almost any utf8 sequence as key, with a small number of 
> exceptions such as '=', '[' and low ascii. In particular '-' and space are 
> often used in key names used by KDE applications.

Ok. I've been questioning myself whether or not spaces should be
allowed. I'll investigate if spaces are allowable. On first sight I
don't see a problem with allowing spaces.

> Comments for section 5.7:
> 
> 1) The schema definition misses support for defining enumerations as type.
> 
> Suggest to add:
> 
> <!ELEMENT enum (choice*)>
> <!ATTLIST enum name CDATA #REQUIRED>
> <!ELEMENT choice (description*)>
> <!ATTLIST choice value CDATA #REQUIRED>
> 
> name attribute of an enum can be referred to in the name attribute of a type.
> 
> The enum element can be a child of the node element so that a single enum can 
> be used for multiple schema.

Ok, I'll take a look at this

> 2) It's unclear what the item attribute of the schema element is for.

The name of preference (last component of the key). But since it's
unclear what it meant, it means that "item" is probably not a good name
for it.

> Comments for section 6.2:
> 
> Including type information at the transport level makes it impossible to 
> support backends that do not provide type information such as KDE's .ini 
> files. I do not see the value of typing at the transport and backend level, 
> especially since the type information provided covers only a subset of all 
> the desired configuration types in a configuration system. The schemas 
> already provide much more detailed type information about keys, including 
> range restrictions.

Skipping this one (discussion about it happening on xdg)

> Comments for section 6.5:
> 
> It should be possible to change multiple values in a single atomic (logically 
> speaking) operation. Something like SetValues(STRING root, DICT data) 
> mirroring the GetValues call from 6.4.

Might be a good idea, yes. Going to investigate.

> Comments for section 6.9:
> 
> Instead of sending a signal for each key I suggest to change the signal to
> 	KeysChanged(STRING root, ARRAY OF STRING keys)
> or perhaps
>         KeysChanged(STRING root, DICT data)
> mirroring the GetValues call from 6.4. With the distinction that for each root 
> a separate signal is send (no keys from "sub-groups" are to be included)

This might be more difficult. Anyway .. investigating.

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