A draft for a standard for desktop configuration

[Waldo Bastian]

On Monday 12 September 2005 14:36, Philip Van Hoof wrote:
> On Mon, 2005-09-12 at 14:32 +0200, Philip Van Hoof wrote:
> > You can find the proposal itself (it's source) here:
> >
> > http://cvs.pvanhoof.be/cgi-bin/viewcvs.cgi/desktop-config-standard/
>
> If you don't have the tools installed to build the PDF:
>
> http://www.pvanhoof.be/files/desktop_config_standard.pdf
>
> Note that this is the 'current' version. The contents might change in
> future, don't refer to it.

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

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.

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.

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

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.

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.

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)

Cheers,
Waldo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20050912/527fc687/attachment.pgp