Configuration API

[Dave Cridland [Home]]

On Thu Apr 29 15:29:53 2004, Waldo Bastian wrote:
> At the storage level, KConfig considers all values utf-8 strings. When the 
> application asks for the value it specifies the desired type and only then 
> will the value be converted to that type. With KConfigXT we generate code 
> for 
> the access methods so that we get type-safety from the compiler based on 
> the 
> type specified in the meta-data. In both cases the backend has no actual 
> knowledge about the type.

Ah, interesting - I had assumed that the backend might know the type. In 
GConf's case, it does.

> 
> > Apart from all that above, GConf has supported atomic changesets for a
> > while, but it's a little used feature - does this have to be mandatory to
> > support? (I don't think so.) ACAP also supports this. I'm guessing LR does
> > not, and I have no idea about KConfig.
> 
> All updates to a single file (our highest grouping level) are atomic in the 
> sense that they all fail or all succeed. KConfig gives basically no 
> guarantees for read-modify-write cycles, (in particular, if two processes 
> try 
> to add 1 to a numeric config entry, the end result will either be +1 or +2) 
> in KDE 3.3 we hope to improve that and offer optional atomic support for 
> such 
> cycles as well.

In around 1996, the ACAP WG looked heavily into locking, which was originally 
in the specification, and decided to dump it. There's not much record of this 
discussion, unfortunately.

> 
> > Finally, do we allow a conditional store: 'change this, but only if it
> > hasn't been changed by anyone else'. GConf doesn't, ACAP does.
> 
> What are you going to do if it has? Provide the user with Bugzilla style 
> midair collisions? I guess it is a good alternative for locking because I 
> don't think it is a good idea to hold locks on entries pending user 
> interaction.

Exactly - the locking is effectively internalized, and it not only works for 
the increment case, but also for several more.

A relatively high-level API could then provide an increment, which is simply:

for(;;) {
	entry = config_read( key );
	entry.value++;
	if( config_store_if_not_modified( key, entry ) ) {
		break;
	}
}

The majority of the discussion appears to have been lost, but it's worth 
noting that very few systems allow for 'long locks' outside tightly coupled 
environments. I can only think of two, in fact - DAV and POP3.

> 
> 
> > Oh, and, of course, is 'set this key to default' the same as 'erase this
> > key' - ACAP says no, GConf says yes.
> 
> KConfig says yes as well.
> 

Aw. I quite like the notion that an application can set something as either 
DEFAULT or NIL. Not a problem, should I write an ACAP backend, of course.

> But if other configuration systems would have problems with that, then it's 
> probably not such a good idea. If they share the same namespace then it 
> should be trivial to treat a sub-group as a single entry, by transforming 
> it 
> into a flat representation of the sub-group. Is that what ACAP does?

Ah, not quite what I meant.

What I meant is, for a given path, can that path both *be* a key, and 
*contain* keys. What keys it contains need not have any influence on the 
value of the key itself.

Dave.