An analysis about a generic desktop application configuration management system

[Richard Moore]

On Mon, Apr 11, 2005 at 05:45:42PM -0400, Avery Pennarun wrote:
> If I want to use konqueror and evolution at the same time, it's a big PITA. 
> If you don't have any problems like this, well, you're just lucky.

Fair enough - I like to stick to one desktop.

> 
> That said, *only* unifying the underlying config API will not solve this
> problem.  You also have to decide on a set of shared keys, which is a
> massive pain in the neck and requires entirely separate standardization
> efforts.

I agree, though a concept along the same lines as we use for interfaces in
KDE could help here (cf. the KTextEditor interface).

> 
> > >       * More easy to migrate from one host to another host 
> > 
> > Again, not really a problem I've every encountered.
> 
> I have.  Keeping my laptop's KDE settings in sync with my desktop ones is
> pretty annoying.  Example: I want different konqueror fonts, because my
> screens are different sizes.

That seems a bit different to migration. Surely the existing systems like
KDEDIRS can deal with it though?

> 
> > >       * Can be platform independent (there's many reasons why this is
> > >         useful)
> > 
> > KConfig already is, what do you mean? I'm sure Gconf is too.
> 
> Does it run on Windows?  If it does, will it store things in the registry,
> where Windows people are expecting their configurations to be stored?

Yes and no repectively.

> 
> (Of course, I'm not sure D-Conf is attempting to solve this problem.  But
> that sounds like what the above requirement is asking for.  UniConf can do
> it already, BTW, if you want.)
> 
> > >       * There's a need for an IPC system that can do signalling and that
> > >         is widely accepted by most free desktop application developers 
> > 
> > Well, I'd say DCOP. :-)
> 
> "Widely accepted by most" might be an exaggeration of the current situation,
> but DCOP is pretty cool.
> 
> > >       * The system should be network transparant and an IETF protocol
> > >         for configuration access would be nice. 
> > 
> > Why? I think latency would kill network transparancy here, and I don't
> > see why the IETF matter either.
> 
> UniConf's network protocol is extremely network-friendly and has been
> designed to minimize latency.  It works fine.  (To do this properly requires
> putting caching in all the right places, of course.)
> 
> This is not to say you have to use UniConf - just that we've already proven
> that this can be done, so people who say it can't are just plain wrong.

I'll take a look.

[snip]
>  - D-BUS is not just for desktop stuff, and has nothing to do with X
>    (although it could be extended to communicate over an X server instead of
>    a Unix socket, since that makes sense on a desktop).  My company will
>    probably end up using it in an upcoming version of our server OS, and
>    there's certainly no X server installed.
> 
> So it seems likely that D-BUS will be acceptable to everyone, while there
> are a few reasons why DCOP might not be.

IIRC DBUS currently lacks some of the features of DCOP. That said, maybe
it will.

> 
> > >       * Glib and GObjects (chosen because it eases the creation of
> > >         interoperable libraries)
> > 
> > Over my dead body.
> 
> Don't worry, I'm sure this requirement won't actually happen.

Which? GLib or my death?

> 
> > For me to be the least bit interested in this idea I need to see:
> > 
> > 1) Significant improvements for app developers vs. KConfig
> 
> Notifications and network transparency ought to provide that.  I think you
> should also add to your requirements, "No worse than KConfig."

I agree notifications and network transparency would be nice. Certainly for
the former, adding support to KConfig would be easier than any change of the
underlying implementation.

> 
> > 3) No loss of easy of use (eg. by using chmod vs. SQL GRANT).
> 
> If the new config system requires you to set up an SQL server, it will
> certainly fail.  If it *allows* you to use SQL if you want, well, that's
> neutral to me.

I don't see a problem with allowing SQL, but think it will essentially
be a DB implmenting a tree which seems pretty silly.

Cheers

Rich.