A draft for a standard for desktop configuration

[Dave Cridland]

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:
> > >
> > > 
> 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
> 
> 
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 
to it.

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.

Section 6.1:

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

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 
> restrictions.
> 
> 
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 
accuracy.


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

Dave.