Configuration API

[Dave Cridland [Home]]

On Mon May  3 16:56:51 2004, Lars Hallberg wrote:
> Dave Cridland [Home] wrote:
> 
>> I can't help but think that we have to, as our first priority, ensure that 
>> GConf and KConfig can rapidly adopt whatever we decide on with a minimum 
of fuss, otherwise we're whistling in the wind. While I'm a great fan of 
albino pachyderms of all varieties, we've got a good opportunity to unify 
configuration between desktops here, and it'd be a real shame if we made 
requirements which prevented uptake.
> 
> I think the API can be prety flexably. If ther is *one* app that uses som 
> complex structur in ther config files, we might consider suporting it, but 
only that bakend need to suport it! Of, corce - this might more be a problem 
for the frontends, that have to suport every feature from every backend.
> 

Argh! No! If we don't have a consistent data model which is supported across 
all backends, we're doomed. I think this is easily achievable between KConfig 
and GConf, with only mild alterations to both.

> 
> On the other hand, a front end can resort to string representation of some 
> uncommon types, and lett the backend do the syntax checking (if we make 
sure the API *alow* every key to be treated as a string as an alternative, 
regardless of actual type).
> 

Which raises an interesting question - is the datatype soft or hard? Meaning, 
can an application say 'give me the value of this key as an integer'? ACAP 
does this to some extent, but for our purposes, I'd say no. Moreover, I'd say 
a backend shouldn't be handling validation - that should always be the job of 
the application using it. Apart from anything else, type checking is a simple 
addition to the validation that has to happen anyway.

> 
> Actuly, the whole API might be strings wher typ info is only used for 
> syntax checking. Then helper libs on top of the API can provide nativ 
datatypes for different environment.

I've suggested something similar elsewhere in this thread, at least as far as 
native type support is concerned. I'm not wed to it, mind, and I'm well aware 
that such types as a list should be easy to support in any backend without 
recourse to converting the entire list into a single string.

Sean Middleditch also suggested backends might be queriable for which 
datatypes they support natively - this is also quite sensible.

Dave.