Configuration API

[Dave Cridland [Home]]

On Wed Apr 28 08:32:44 2004, George wrote:
> On Tue, Apr 27, 2004 at 03:59:22PM +0100, Thomas Leonard wrote:
> wheras what really would be useful to be shared is the backend.  That is,
> GConf is already an API for GNOME and I bet KDE folks are just as happy with
> their own API.  As long as we can plug shared backends into the native APIs
> then there is no need for an FD only API.
> 
> Basically it's all in the backends.  I bet writing some glue code to be able
> to use one set of backends would be most useful here.  It would not tie 
> anyone
> to any specific API (people are already tied) either.

Oh, I agree wholeheartedly. Almost.

There's just one slight snag, and that's that KDE and GNOME (and everything 
else, too) use different data models. KConfig uses a restricted depth, as I 
understand things from Waldo's post a while back, whereas GConf doesn't, just 
as an example.

Moreover, it'd be nice to have an API available, if for no other reason than 
it'd be handy for new 'desktop neutral' apps, or indeed non-desktop apps.

Which has reminded me - it'd be nice to examine wxWidgets configuration 
classes as prior art in this area, too - that provides a C++ desktop-neutral 
API for accessing configuration on Windows (via the Registry) and UNIX (via 
flat text files).

Perhaps as a first step, we should make a list of all prior art - recent 
threads, including The Thread That Ended, produced a significant amount of 
prior art.

I can think of, in no particular order:

 - GConf
 - ACAP
 - LR
 - KConfig
 - Config4GNU
 - wxConfig
 - Windows Registry

I'm sure there's a whole bunch I'm missing.

We could also try to look at the data models employed by the likes of 
Apache's config file, and a few other text-driven config mechanisms.

Note that I think we need to figure out what data models are in use, and 
whether we can unify them, before jumping to any conclusions about how to 
actually deal with the implementation issues of a common configuration source.

Dave.