Configuration API

[Lars Hallberg]

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.

So, if the existing stuf easely translate to a tree of keys, that might 
be preferable.

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

'Midelware' that have to pass calles from one instance of the API to 
another, probably prefere to do it as strings anyway (thay have of corse 
to pass the type info, syntax error messages etc along to).

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.

/LaH