An analysis about a generic desktop application configuration management system

[Philip Van Hoof]

On Tue, 2005-04-12 at 12:56 +0200, Waldo Bastian wrote:

> > Or are bindings for the different programming languages unimportant? I
> > would disagree with such a statement. I'm not going to be the only one.
> 
> I think language bindings only play a role at the client side, and there KDE 
> will want to offer a KConfig compatible API to KDE applications, and perhaps 
> hook it into QSettings for Qt only applications. I expect that Gnome will 
> want to offer something GConf/GObject oriented. I don't see a need for 
> sharing the client side api. KDE/Qt already provides a wide variety of 
> language bindings, so your favourite language binding will automatically get 
> access to DConf settings when KConfig/QSettings start to provide that access.
> 
> I will make an architectural overview to illustrate what I mean.

IMHO, thats a good idea.

> Anyway, in my view the shared part will mostly be limited to the daemon side, 
> keeping that part free of glib dependencies will certainly help to make it 
> more acceptable for KDE. Depending on the amount of processing required at 
> the client side there could perhaps be a small shared part at the client side 
> as well, the same would apply there then.

If there's more hands to make the job lighter, I think excluding glib
from the list of used technologies (in the daemon) is a possibility. The
usage of glib is mainly to ease the creation of language bindings. The
daemon doesn't need language bindings, the library does.

But we shouldn't start abandoning technologies or libraries just because
one person dislikes it. There should be a technical and good reason for
it. And we should ask questions like: What are the alternatives?

So for the daemon the only reason for using glib is to ease the
implementation of it. But IMHO should the choice of using glib be made
by the developers who are going to implement that daemon.

If KConfig or KDE in general or QConfig or any other existing config-
system wants to talk directly to the daemon, that can be made possible.
Provided, of course, that a specification of the protocol (which the
library and the daemon will also have to talk) is going to be made and
standarized.

In that case, I think the freedesktop.org organisation should play an
important role in creating that protocol.



-- 
Philip Van Hoof, Software Developer @ Cronos
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: philip dot vanhoof at cronos dot be
junk: philip dot vanhoof at gmail dot com
http://www.pvanhoof.be/