Configuration API

[Dave Cridland [Home]]

On Tue Apr 27 20:25:40 2004, Havoc Pennington wrote:
> On Tue, 2004-04-27 at 10:59, Thomas Leonard wrote:
> > If we make an API, then people can get started writing backends for it.
> > Eg, someone could make a gconf backend and all programs using the API
> > would get their settings stored using gconf. Someone else could make a
> > Linux Registry backend, or a D-BUS daemon, etc.
> 
> If gconf and the D-BUS daemon and so forth already have pluggable
> backends, why would you layer an additional abstraction API on top?
> 
> Or put differently, if you had the abstraction API on top why would
> gconf or the D-BUS thing be pluggable?

It gives you a potential independance from GConf or D-BUS altogether. This 
may or may not be a good thing, but it does mean that not everyone has to 
agree with everyone else on any aspect of the implementation.

> 
> IMO the lesson from gconf is "slightly too complex" and the lesson from
> straight to text files is "not quite complex enough" and the happy
> medium is in between. But refusing to choose one is inherently more
> complex than either alone. Making it configurable is the *wrong* way to
> compromise, it's design-by-committee yuck.
> 

GConf too complex? Possibly in implementation, but I'm not sure I really 
agree with that either. I do know that a lot of its functionality - things 
like changesets - were never really picked up on, as far as I've seen, and 
that code does add a lot of complexity. But basically, it looks okay to me. 
Just a shame that nobody ever uses it with a different backend to the default.

Making the backend of a configuration system switchable is not, I feel 
'design by committee', which is indeed a terrible thing that has given us 
horrors such as email, TCP/IP, and, oh, wait.

No, making the backend switchable does, in all seriousness, give us the 
opportunity of quickly and easily testing different backends, some of which 
will emerge as leaders in a particular deployment pattern. As Sean says, some 
folk will want a heavyweight, network-aware backend, and others will benefit 
more from a lightweight system. If GConf has any serious failings, it's been 
in trying to reconcile the two in a single daemon. (Now, of course, GConf 
effectively has a compile-time switch to be network aware or not.)

Dave.