A draft for a standard for desktop configuration
dave at cridland.net
Tue Sep 13 01:32:36 EEST 2005
On Mon Sep 12 22:26:38 2005, Waldo Bastian wrote:
> 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:
> > >
> > >
> > 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
> instead of hardcoding /usr/share/configuration
If schemas are local, then a remote configuration server cannot
provide defaults sourced from them.
Personally, I feel that sane defaults should be either generated by
the application itself in the absence of data (in which case, they're
only documentation in the schema) or handled by stacking (which
complicates application installation).
> 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.
While I agree that the names given are too restrictive, I think a
recommendation to use plain ASCII would be sensible. We do need some
reserved characters, though. Perhaps "*%/.?"?
Introducing UTF-8 means that should a human read a key name and
retype it, or simply copy and paste, it's possible to end up with a
different octet-sequence which no longer matches the key name. You'd
need to mandate some kind of stringprep to handle it right.
UTF-8 is one of the things ACAP did that went wrong, IMHO.
Section 5.4 is wrong, as well. I know what it means to say, but it
doesn't say it.
In any case, please consider adding a /~ component at the top. It
means that we can rapidly extend the entire system to have a
management layer which *doesn't* have /~ at the top. (But, perhaps,
has /user/dave instead).
Section 5.5 contradicts section 5.3, it seems. Or else needs to refer
No mention is given of whether it's possible to have both a key
called "foo" in "/org/stuff/", *and* a root "/org/stuff/foo/". I have
no opinion on that technically, but I suspect it'd be a whole heap
less confusing if a particular path either pointed to a key, or a
root, but not both.
Personally I have a serious problem with validating on the server.
There are so many pitfalls and security issues here that I'd much
rather see the application validate. It is always more aware of
correct values than the server. Invalid values should be ignored,
replaced with defaults, or whatever else is most suitable for the
Some cases where server validation fails includes network
environments where different client hosts have different application
versions on them.
> 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
Agreed. Everything's a string. Or, alternately, have the application
request the data as the type it wants.
Also, INT64 for UNIX timestamps? I agree that the effectively 31 bit
UNIX timestamp is too small to be future proof, and I see the benefit
of a timestamp, but I'd suggest that you used one with subsecond
> 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.
I'd also add an optional timestamp value of the last known change,
and if supplied, and "incorrect", reject the store. It's cheap
atomicity, and basically gives you transactions without having to
actually have transactions. Both ACAP and IMAP's CONDSTORE extension
do this, it's a neat design.
However, it'd really be better to use an opaque magic number for
this. Say an INT64 that always increases on any change. Then you
don't have to care about maintaining time sync. You can still have
timestamp data in the metainfo if you like, for informational
purposes. CONDSTORE does this, ACAP uses "things that are mostly
timestamps, but not completely", which essentially behave the same.
Either way, it's useful for finding both which items have changed,
and in what order, which makes network based systems much faster.
More information about the xdg