D-Conf

[Sean Middleditch]

On Fri, 2005-03-04 at 16:12 +0100, P. Kaluza wrote:
> Avery Pennarun wrote:
> >Definitely true, except that it pretty much has to be rewritten from scratch
> >in order to become cross-desktop.
> >
> If you have to completely rewrite something to replace one IPC mechanism 
> with another, at least one of your IPC mechanisms would be rather 
> broken. But I don't think this would be the case for GConf.

The GConf developers want to do some major overhauls.  And, again, CORBA
isn't something certain groups want to touch, and it is basically
'bloat' when you consider that the standard IPC mechanism of FreeDesktop
is very likely going to converge on D-BUS over time.

> >Note that D-BUS is still intra-computer only (that is, it doesn't use the
> >network).  I don't see why nobody has extended it to network awareness yet,
> >since it looks like it would be easy, sensible, and reliable, but they
> >haven't.
> >
> 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 should *allow* a central configuration repository with
> >   default/current/override settings.
> >  
> >
> Yup, allowing for multi-level configuration from day one will certainly 
> help acceptance. (I envisioned Schema Defaults/Distributor/ Site 
> admin/Computer admin/User, with Distributor, Site admin and Computer 
> admin having the ability to "lock down" certain keys.)
> 
> On Daemons:
> I can understand why for the "System scope" you'd not necessarily want 
> to involve a daemon - boot-time complication and security questions come 
> to mind. However, when talking about a desktop system, you really really 

More to everyone in general on this topic, not specifically a reply to
this post:

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.

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?"

-- 
Sean Middleditch <elanthis at awesomeplay.com>