Preparing GConf for the next generation (D-Conf related)

Tue Mar 8 14:41:56 EET 2005

On Tue, 2005-03-08 at 12:02 +0100, Mikael Hallendal wrote:
> Philip Van Hoof wrote:
> 
> Hi,
> 
> I'm a bit confused here. Are you tearing GConf to pieces out of guesses 
> on what you think needs to be done or do you have a list of requirements 
> that you haven't posted (or I have missed)?

> What I think would be the best piece of action that should be done long 
> before starting to do any actual hacking on the library it self is to 
> define what would be needed.

> That is, what is lacking/need to be removed from GConf in order for it 
> to be a viable solution for KDE, OpenOffice etc. And while doing that 
> also get a clear view on what is currently lacking for GNOME.

I've been studying the current GConf code. And now you ask; my personal
view on whats lacking/need to be removed from GConf is the following
list of items*. Note that it's a personal view. It's my opinion so this
doesn't necessarily means it's the truth.

I wanted to learn and understand the current GConf code. The tearing
GConf into pieces is part of my learning process. I might have named it
"GConf-3" but I haven't yet said that it's indeed the future of GConf-2
per sé. It's (as you stated in a prive mail) a playground to see what
can be done with the current GConf-2.

* The list

Build environment
=================

GConf needs a clean build environment that isn't trying to build Gtk+
sanitychecks or test applications if it can find a Gtk+ development
environment. That isn't trying to make it also possible to build GConf
with ORBit-2 as IPC (only support DBUS). That separates different
build-targets also in directories rather than putting sources of the
library, the sanity-check, the gconftool and the daemon in the same
directory. That has clean and maintainable Makefile.am and configure.ac
files.

Design
======

o. A very simple message-orchestrating daemon that delegates storing the
configuration-data to a pluggable backend. One that communicates with a
client-library (get and set) and that will notify clients who are
listening for key/value changes on specified keys. GConf is already
doing this but a.t.m. it utilises ORBit-2 for it.

	- The communication should be DBUS rather than ORBit-2. There's
	  a prove of concept branch in GConf's CVS that will replace
	  ORBit-2 with DBUS. But it's design is to replace ORBit-2 with
	  DBUS with as few changes possible (for keeping the patch
	  maintainable). I prefer calling this a prove of concept-hack.

	- There's good reasons why it was done as a hack (and I do
	  understand those reasons). Nevertheless it needs a major
	  redesign.

	- For example: The notification should be done, if DBUS as IPC,
	  with the signalling stuff. DBUS has support for signalling
	  (events on the bus). The GConf-on-DBUS POC is currently
	  reimplementing this feature to keep te patch between the
	  corba-only and the dbus+corba version of GConf small and easy.

o. A default backend that stores the configuration data in XML. It's
data should be backwards compatible with older GConf releases or it
should not break older GConf installations. In fact running KDE or GNOME
1.4, 2.2, 2.4, 2.6 and 2.8 in the same $HOME directory should still be
possible after migration happened. It's not a requirement to let all of
them reuse the same configuration-data, but any new system shouldn't
break or destroy it.

o. The possibility to create new such backends.

o. The three most-important items of the plan which Havoc wrote down on
this webpage:

	http://www.gnome.org/projects/gconf/plans.html

Again .. this is my personal view.

I'd dislike yet another flamewar. I'd like to keep the discussion
technical. I think most of the developers interested in building a
generic configuration system have a very equal view on the overall list
of requirements. It's an almost perfect match of the requirements or
current feature list of GConf-2.

Further discussing the list of requirements seems to go in the wrong
direction. It's becoming a thread which is basically saying that this
new system is going to have to solve all of the problems in this world.
This isn't true. In fact it has to focus on a very specific problem:
handling the configuration of DESKTOP applications.

I, personally, am not interested in developing a configuration system
that will try to take care of configuration that isn't for desktop
applications only.

> After that merge these thoughts into a list of things that would make a 
> different if we change and talk this through with the GConf maintainers 
> to get an idea from them if it's a good idea from GConf's point-of-view...

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