Configuration API

[Dave Cridland [Home]]

On Fri Apr 30 15:05:02 2004, Sean Middleditch wrote:
> The backends would have access to these "format" types as well, and so
> they can do whatever they want with them.  If we're talking, say, a date
> string (base type string, format date) with a SQL backend, it might be
> stored using a DATE column type or something.  The API could of course
> have an error code for the set_key function like ECFG_FORMAT_SYNTAX or
> something.  The standard would specify the syntax, and apps that don't
> follow it might get this error with certain backends.
> 

I can't actually see that being possible, unless a key's datatype is codified 
somehow very early on - otherwise you'll have a SQL table with a huge number 
of columns, of which one will be used depending on the datatype.

I do think most backends will be able to handle lists, though. Arguably, a 
backend could simply tell some upper layer what fundamental formats it 
supports, and let the upper layer handle specific datatype handling.

> 
> I don't think the core library itself should do this syntax checking
> because the number of special formats we have could get very large, very
> quickly.  We want to keep the core library lite.  I'm not convinced
> it'll be that big of an issue, either.
> 
> It's also possible to write a "debug" backend that layers over any other
> backend but provides mandatory syntax checking of special formats so
> developers can test their application.
> 

Total agreement on both.

> 
> > 
> > >Yep. I think people should be able to buy into a shared config system
> > >without having to accept our schema language. We should propose a shared
> > >one separately (the Config4GNU team will have a lot of ideas here, I'm
> > >sure), but it should stand on its own merits.
> > >  
> > >
> > If it is possably to make optional in a clean way, thats good!
> 
> No reason it wouldn't be.  The get_schema call might just not return a
> schema.  The documentation should still stress the importance of a good
> schema, however.  And any schema format developed should be easy to
> author.  Over-engineered XML files are something we don't need.  ;-) 
> XML does allow us to go back to the multiple layers of difficulty. 
> (Just as in my proposal apps can just use core types, or additionally
> use the format specifies.)
> 

While I quite liked your suggestion of a possible schema format, there is 
extensive prior art in this area. In particular, GConf's schema files have 
much of what you want, although lang is called locale instead.

(GConf also uses per-locale defaults, although I'm not sure how much these 
>> are used in practise. I really ought to examine GConf usage a bit more - 
I'd really like it if pairs vanished, for instance, since pair<int,string> is 
more complex to handle than list<string>)

Dave.