configuration system notes

[Havoc Pennington]

On Thu, 2005-04-07 at 12:29 -0400, Avery Pennarun wrote:
> 
> I would argue that UniConf-DBUS is a valid way to implement the daemon part
> of the new gconf spec you have posted

Sure, maybe it is. I'm not saying "because UniConf has multiple backends
it can't be used" I'm saying "multiple backends are a big *shrug* and
not really crucial to the programmer, sysadmin, or end user experience"

The problem with this whole conversation is that people are going down
ratholes about hypothetical performance issues, file formats, early
boot, and whatever else; and none of that is really the important part.
GConf's backend sucks, it doesn't work for early boot, and it has bad
performance; but it's _still better_ than a lot of these other systems
and proposals on the dimensions that matter. If people don't understand
that then they won't successfully replace GConf.

In my view the big picture of GConf is mostly right and well-tested in a
GNOME context (with a couple of flaws, most notably the mistake of
putting schemas on server side). To improve on GConf you have to keep
that big picture working, AND ONLY THEN does it matter whether you fix
the small picture items such as performance and CORBA dependency. The
person who understands this point is going to successfully write a
replacement.

I'm sure from the KDE point of view the same point holds for KConfig.

Here's an analogy I like to use: the point of the iPod for many people
is a portable music library, so you can listen to all your music. You
could say that a flash ram player is less fragile, smaller, and
otherwise has better features; but you would be completely missing the
point, because I can't listen to all my music if I only have 64M.
(Unless my flash ram player had a random subset of my music shuffled in
every morning... cf. how Apple did their flash ram player)

So, let's get it out of the weeds.

Havoc