D-Conf

[Avery Pennarun]

On Fri, Mar 04, 2005 at 10:40:14AM -0500, Sean Middleditch wrote:
> On Fri, 2005-03-04 at 16:12 +0100, P. Kaluza wrote:
> > I think it's a safe bet to say that, by the time it hits 1.0, D-Bus will 
> > have network transparency.
> 
> It's not safe to say that at all.  I don't think anyone is even working
> on that, from what I've read on the dbus list.

It's safe to say that D-Bus will have network transparency *eventually*,
because I'm going to do it myself if I have to.  D-Bus is too useful to
me specifically to *not* make it network transparent.

When will I do it?  Yeah, well, maybe I'll make netselect 1.0 someday too :)
But think of it this way: current GConf isn't network transparent, and it's
not killing anyone.  Making D-Bus network transparent will be *less* work. 
It's obvious that GConf should use D-Bus.  So it's going to happen, if it
needs to happen.

> Does this hypothetical configuration system REALLY need to be designed
> to handle early boot up or anything like that?  Is that perhaps just a
> tad bit of over-engineering for a DESKTOP configuration system?  Does
> early bootup even NEED a new configuration system?  Do the early bootup
> guys WANT a new configuration system?  The target of the new
> configuration system is desktop apps, so there's not a whole lot to gain
> by worrying but applications outside your target application set.

You're arguing against something that is no work.  The only unusual
requirements for an early boot config system are:

 - doesn't require a daemon

 - doesn't have a lot of weird dependencies because /usr might not be
   mounted.

GConf (the D-Bus one) and Elektra already meet both requirements.  (It seems
to be a little-known fact that you can run gconf without a daemon.)  Not
worth arguing about, because it's supported whether we do any work or not.

Should fd.org do any *work* to support a boot time configuration system? 
Probably not.  It's the free-desktop project, after all, not the free boot
time project.

> Does the configuration system really need multiple backends, instead of
> just writing one good one and leaving it at that?  Aside from a single
> fast, efficient, secure, safe local-storage mechanism and a single
> usable remote-storage mechanism, what other backends could you need?  I
> don't care about the geek factor; just because you can make a new
> backend doesn't mean you should.  If there isn't a very strong case for
> NEEDING to switch backends...  If you do need to switch backends, is it
> worth coding them up as dlopen'd libraries, or is the fact that you can
> swap in a different D-BUS daemon that uses the D-Conf service a good
> enough mechanism for changing "backends?"

This is a lesson I learned the hard way, so please take my advice: 99% of
the people use less than 80% of the features of a complex product, but every
one of them uses a *different* 80%.  If you only implement 80% of the
features, you won't get 99% of the people; you'll get none of the people.

But if you make a system that comes with the basic 80% of the features but
can be *extended* to have 99% of the features, then you can work your way up
to the 99% of people you want.

Don't leave out pluggable backends.  Not that you were going to have the
choice, since all the systems under consideration already support them.

Incidentally, replacing the daemon that answers D-Bus configuration requests
(equivalent to the gconf-dbus-daemon, I guess) is a perfectly sensible way
to have pluggable backends.  That's because you still have a gconf frontend
that sends those DBus messages, so the part you replaced must be the
backend.

Have fun,

Avery