An analysis about a generic desktop application configuration management system

[Avery Pennarun]

On Mon, Apr 11, 2005 at 10:12:22PM +0100, Richard Moore wrote:

> >       * Desktop applications from all environments can work together
> >         with a few common configuration-settings. There will be no more
> >         need to duplicate these settings 
> 
> For me, this is a non-issue (I only care about KDE).

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.

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.

> >       * 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.

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

(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.

The IETF doesn't matter much to me in this case.  They should stick to their
original intent: standardizing protocols that people are already using.  If
D-Conf includes a protocol and lots of people want to use it, well, great. 
Standardize it then.

> >       * The programming language C (chosen because it eases the creation
> >         of interoperable libraries)
> 
> I disagree, you can bind things fine with C++ and get a better
> expression of your design.

I agree that the core language of the system is kind of irrelevant.  It
obviously needs C bindings for Gnome, and C++ bindings for KDE, and maybe
other bindings for other systems.

> >       * The IPC system D-BUS (which will need some improvements first)
> 
> Again, I prefer DCOP.

As an actual system-level programmer (I profess no particular love of
*either* KDE or Gnome), I have to say, D-BUS is pretty awesome.  I also like
DCOP, but it's not quite as universally applicable as D-BUS is.

Also, did you know:

 - D-BUS doesn't have to use glib mainloops or libglib; if you want, you
   could bind it directly into a Qt event system.

 - D-BUS was designed with DCOP API compatibility in mind, so it should be
   pretty easy to take DCOP apps and have them use D-BUS instead.

 - I wrote WvDBUS wrappers in C++.  It was easy, and made DBUS quite easy to
   use.

 - 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.

> >       * 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.

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

> 2) No addition of stupid dependencies likes GLib to kdelibs

glib is actually a pretty nice, small library that more and more people (eg.
gstreamer, potentially to be adopted by KDE) are starting to use outside of
Gnome.  So Linux systems are pretty much going to have glib in them whether
you like it or not.  But there are lots of other glib-related libraries you
probably want to avoid relying on.

> 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.

Have fun,

Avery