An analysis about a generic desktop application configuration management system

[Avery Pennarun]

On Mon, Apr 11, 2005 at 11:39:38PM +0100, Richard Moore wrote:

> On Mon, Apr 11, 2005 at 06:35:39PM -0400, Avery Pennarun wrote:
> > Actually, I've personally ripped out and replaced all of KConfig's
> > implementation to make it talk to UniConf instead, so I know quite a bit
> > about how KConfig works.  (I don't know much about KConfigXT, but it seems
> > separate from this question.)
> 
> Neat, did you try doing it as plugin backend?

Actually yes, that's what I did.  See the 'unity' project in anonymous cvs
at open.nit.ca.

It just turns out that most of KConfig's implementation is in the backend. 
(Which is very sensible, since most of the work is in reading/writing the
files and storing them in a memory structure, all of which would vary by
backend.)

I had to replace the KConfig frontend library as well, unfortunately,
because of this in kconfig.cpp:

  // for right now we will hardcode that we are using the INI
  // back end driver.  In the future this should be converted over to
  // a object factory of some sorts.

Heh.

> > I can say I'm pretty sure KConfig will mostly need to be redesigned - on
> > the inside, not the API - in order to implement cross-process
> > notifications.  The problem is that to get cross-process notifications,
> > you'll either need a FAM-like thingy, a daemon, or at least broadcasts
> > over something like DCOP.  All of these are major implementation changes
> > that add up to about as many lines of code as KConfig already has.
> 
> I'm not sure you actually need cross-process, surely simply listing the
> config files you're interested in is enough?

But if the control panel changes a setting and konqueror is supposed to
notice, you have to provide a way of telling konqueror about it.  That's a
cross-process notification.

It's not the end of the world: it's just work that has to be done.  To do it
really reliably, especially with network transparency, is a lot of work that
has *already* been done by others.  The question is whether to use someone
else's work (and thus do the work of making a frontend-to-backend binding)
or to do that work yourself (and save the work of switching backends). 

IMHO, the former is easier.  But it depends on having a backend you actually
want to use, which I think we can agree that glib, CORBA, and SQL are not
particularly.

> > Of course the API would also need to be slightly extended to allow you to
> > register for notifications, but that would be backwards-compatible (you
> > don't *have* to register if you don't care) and easy, so it's okay.
> 
> That could easily be added as a factory method that returns a QObject.

Yup.

Have fun,

Avery