configuration system notes

[Avery Pennarun]

On Thu, Apr 07, 2005 at 12:10:11PM -0400, Havoc Pennington wrote:

> On Thu, 2005-04-07 at 11:50 -0400, Avery Pennarun wrote:
> > While it is certainly true that UniConf punts many important decisions that
> > are actually very important to how the configuration system should work, its
> > configurability cannot possibly be considered a disadvantage.
> 
> Let me put it this way: I think you could write a version 1.0 system
> that met the needs of Fedora, GNOME, and KDE _without_ pluggable
> backends.

Sure.  But that would involve writing code that doesn't exist yet, whereas
UniConf does.

> The interesting future backend is a client-server one, maybe using a
> directory server, but that's an enterprise feature that so far nobody
> has even bothered to do for GNOME or KDE in the last few years because
> every enterprise has some hack for dealing with text config files
> anyway, since UNIX/Linux more or less requires you to have a hack like
> that.

UniConf also has this already, because that's the backend *we* really
wanted.

> So, if I were designing a system I would keep the API opaque so I could
> add backends, but multiple backends would be the last thing I'd add, not
> the first. Most other goals are more important.
> 
> Multiple backends aren't a disadvantage, but they are the wrong focus.

I'm not sure why you're blowing this so out of proportion.  Multiple
backends fall automatically out of a good software architecture, which
UniConf is.  The actual loading of dlls is a tiny amount of work compared to
proper registration for notifications, parsing/storing xml files, caching
keys appropriately, or whatever.  It is simply not a mistake to have
already-implemented, working, well-tested code for a desirable feature that
is just not at the top of the priority list.

Should we implement features that *are* at the top of the priority list?
Well, of course!  But let's just do that.  Unimplementing the lower-priority
features is a pointless exercise in the meantime, especially since this
particular lower-priority feature makes it easier to implement your high
priority ones.

I would argue that UniConf-DBUS is a valid way to implement the daemon part
of the new gconf spec you have posted, and it has the advantage of already
being done.  You can even store that data in old-style gconf, because of the
pluggable backends.  The missing part is the schema-enforcing client
part, but that part just plain hasn't been written by anyone anywhere for
anything.  (Which makes me suspect that it's not as important as you think.)

Have fun,

Avery