Configuration API

[Thomas Leonard]

On Tue, Apr 27, 2004 at 03:25:40PM -0400, 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?

Sorry, I meant someone could adapt the gconf backend to be a backend for
the new system. Or put the gconf frontend on the new backend.

Of course, it might turn out that the gconf backend API is ideal already.
In that case, we should try to get everyone using it instead of creating a
new one.

Likewise, it may be that the gconf frontend API is ideal. In which case,
we need to find out why KDE, apache and gimp aren't using it.

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

The trouble is, I think a lot of programmers won't use a configuration
system that adds a dependancy on either a daemon or a database. However,
others won't go for a system that doesn't support these. Are you planning
to pick just one type of system (eg, daemon+D-BUS) and support only that?


-- 
Thomas Leonard			http://rox.sourceforge.net
tal00r at ecs.soton.ac.uk	tal197 at users.sourceforge.net
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1