DConf configuration system

[Sean Middleditch]

On Wed, 2005-04-06 at 17:33 +0200, Buola Buola wrote:
> On Apr 6, 2005 5:18 PM, Sean Middleditch <elanthis at awesomeplay.com> wrote:

> > Why should it have folders and all that?  It really shouldn't be
> > anything more than a key/value database.  The keys might look something
> > like UNIX paths, but that doesn't mean they are - the engine doesn't
> > need to specially recognize the / character or anything.  Making it
> > actually folder-based doesn't buy you anything, but it could potentially
> > complicate backend code.
> > 
> I don't think that it's a problem that backends have to recognize the
> / character specially... we could even use some escaping mechanism if
> it is necessary.
> I think it actually simplifies things because then we can provide a
> DBus object for every folder (I think it is too much to do it on a key
> basis) and be able to receive notifications per folder. It's then also
> possible to do commands like "retrieve all keys in that folder" and
> such things

That's the problem.  Doing it that way will severely complicate some
backends.  If you want individual backends to break things into folders
and all that, fine, but the normal API shouldn't require it.  I can make
a very efficient SQL backend, but not if it gets broken into folders.
Without folders, it's just a simple table of name/value pairs (and some
other meta-data) that you can do very fast lookups on.  The string
matching can also be used in SQL queries for very fast lookups.  All of
which you lose when enforcing folder-based access.

> It also makes it much easier to namespace configuration keys

Not any easier than the string matching I presented.

> > Backends could go ahead and break things into folders if it helps them,
> > but they shouldn't be forced to.  A pretty efficient and fully function
> > SQLite backend could be implemented with very little code using plain
> > string keys.
> Same applies the other way round. Backends can unbreak folders into
> full keynames if it helps them.

Why make them do that, though, if they aren't going to use folders?  The
actual DConf API is, I'd imagine, going to be string based.
set_key("/foo/bar/blah", val) and so on.  Making the API object based
will just complicate what should be very simple to do.

If a backend uses folders for internal representation, it can do the
breaking of strings into folder objects instead of the client.  And if
the backend doesn't use folders, no conversion is needed at all.  Your
method forces the breaking of strings into folders for all backends,
even the ones that don't want it.  My method allows the breaking of
strings into folders, but only when needed.

The strings stuff is also just a lot simpler all around.  Simpler code
may not always be faster (though a good SQL backend could make it very
fast in this case), but simpler does generally result in easier to
maintain and less buggy software. ;-)

> 
> > 
> > > - The different backends will be "mounted" somewhere into this
> > > filesystem, so for example you could have a GConf backend mounted at /
> > > and then some other systems mounted on it.
> > 
> > Why?  Just for kicks?  Sounds like over-engineering something just
> > because you can or because it sounds cool.  You don't even need to make
> > backends as plugins.  If you're using D-BUS, you get swappable backends
> > for free - just setup a different daemon binary as the service manager
> > for the DConf address, and so long as the binary implements the DConf
> > interface, it'll work.  No need for making a big over-complicated
> > plugin-managing filesystem-shadowing singing-and-dancing configuration
> > daemon at all.
> > 
> The idea was to be able to have different backends mounted at
> different points, to make transition easier, and to be able to access
> other configuration systems using this interface. Actually in the

I think you're going about that wrong.  Please, please don't fall into
the trap of over-designing new software to compensate for a short-term
transition phase from old software.  You go and add all this code and
complexity for transitional purposes, and after the transition you're
stuck with all this unnecessary code for a long time.

For the transition, do it somewhere else - for example, in
gconf/kconfig.  Those both have the ability to use different backends,
if I recall - you could write a new gconf backend that uses DConf so
that apps using the old gconf API still work.  That's where you should
put the transitional code - in the software that's getting transitioned
out.  Not in the software getting moved in.

Systems with DConf then would include the DConf-ified g-conf, and all
apps (whether they use DConf or g-conf) will Just Work(tm).  When g-conf
is finally not used any more, it can be removed along with all the
transitional code, resulting in an overall simpler system.

So far as accessing "other configuration systems"... who cares?  What
real, solid good will it do?

> system I have started developing I can access the whole gconf tree at
> /gconf and some kde keys at /kde.
> It will also help mixing the modification of settings for
> non-DConf-aware applications creating a backend for their
> configuration files and using the same interface.

Why not just submit patches for those applications, then, instead of
over-complicating DConf?

> 
> > The multiple backends will also give you all sorts of hell just as bad
> > as you get with UNIX file systems today.  For example, you can't do an
> > atomic creation of a directory tree if that tree needs to span multiple
> > mount points in UNIX.  You'll end up with the same problems in a
> > configuration daemon using multiple backends at once.
> > 
> We will be able to do it because only one process will actually do the
> changes accessing the different plugins, so it will be atomic for
> applications which use this API

That completely will not work for most backends.  You cannot assume that
two backends can possibly perform a single operation together
atomically.  That's why we have a daemon instead of having apps directly
access config files - to centralize all the storage manipulation through
a single unified code path.  You can't guarantee that your file backend
and my SQL backend will both atomically commit their writes safely.  You
simply can't.  And what happens when I bring in my backend that talks
LDAP to a network server?  You aren't going to be able atomically write
a local file and get the remote server to atomically commit changes,
either.

It simply isn't possible to do.  You might make it look to application
running on the local host that commits are atomic, but the second you
get a power failure in mid-commit, the user will quite painfully find
out just how untrue that atomic guarantee was.
-- 
Sean Middleditch <elanthis at awesomeplay.com>