Re: GConf vs. bonobo-config

[Havoc Pennington <hp redhat com>]

Dietmar Maurer <dietmar ximian com> writes: 
> I consider bonobo-config as a chance to cleanup the GConf
> implementation and simplify the internals. But it seems that most
> people think this is worthless, because Havoc is maintaining his own
> code anyway. They don't see that code sharing is a real advantage,
> and that we can gain much from a clean implementation. Instead they
> assume I am totally braindead, sitting here and unnecessarily
> duplicate code - a quite ignorant view of things :-(
> 

I do see the advantage in it. I just think there's some boring drudge
work that needs to be done - we can't just say oh we're replacing
everything screw back compat, testing, useful features, etc.

If you want to clean it up, I would suggest that a) as you've said
there be a bonobo-config backend that can read the current GConf XML
format (which is I agree pretty lame but you can probably recycle the
current GConf backend code instead of having to deal with it) b) add
the features to bonobo-config that aren't there, such as the database
stack allowing workgroup-wide settings and mandatory settings, or
error handling, etc. then c) we could support the current GConf C API
as a wrapper around bonobo-config, without losing user settings.
Or we could simply have GConf use bonobo-config as backend.

(The potential for really elaborate infinite loop bugs here is
fascinating ;-)

But there is no way on earth to do this for GNOME 2. Even if someone
wanted to spend the next two months on it, it'd create a bunch of
headaches for other people, and there are way more useful things to
do. We can always do this later, it doesn't matter API-wise.

There's also the issue of simply evolving the config system to support
some things like multiple sessions better, support sharing your
settings between multiple machines, support a network backend, adding
config support to apps and making it work well, ensuring that
schemas/docs get installed (I'm not sure how you install docs,
"factory default values", and so on with bonobo-config), etc. etc.
So any time spent on just rearranging code is going to take time from
these things, and we need to keep that tradeoff in mind.

I still don't feel like the design/architecture of GConf properly
handles all these features, especially being able to seamlessly move
sessions between machines with a reasonable UI, and bonobo-config
doesn't do it either, so before we rewrite all the interfaces too many
times it'd be nice to figure out how this works.

Another thing I want to keep in mind is that we could eventually have
a desktop-independent way of exposing an API that non-GNOME stuff
would be willing to use. By desktop-independent I don't mean KDE can
use it in particular, just that anyone can use it, e.g. command line
stuff even, and probably you'd need a backend portable to Windows
instead of the UNIX daemon based backend.  Because the more
widely-used a config system is the more useful it is. Anyhow, it does
make me nervous to make the config system simply a careful arrangement
of existing Bonobo mechanisms because that does make it harder to add
this ubiquitous feature to GConf. I think we've benefitted quite a bit
when things are portable and used outside GNOME, e.g. for libxml I
think Windows users find most of the bugs.

So I think these are all serious issues that probably need to be kept
in mind. My reluctance to just dump GConf in favor of bonobo-config is
not that I don't see your code is clean code, I do see that, I just
think there are a lot more considerations that matter in addition to
that consideration.

Hmm to summarize in this mail some features I'm not sure bonobo-config
has, that you may want to consider adding if we're looking at
migrating to it eventually:

 - ability for sysadmins to reset to factory defaults. 
   GConf apps install the schemas to /etc/gconf/schemas 
   or something, sysadmins can use gconftool to reinstall 
   those in a particular database
 - a tool such as gconftool
 - how do the docs and factory defaults get installed when 
   apps are installed?
 - how does localization of docs work?
 - the mandatory settings as mentioned before
 - the list of databases to search, so I can have workgroup 
   defaults
 - error reporting
 - crash robustness

And again, I think whichever config system we use we need to be trying
to solve this issue of multiple sessions and users moving between
multiple machines, and we need to come up with a reasonable network
backend and implement that.

GConf doesn't address all these issues perfectly either. However
again, the reason I keep babbling about syntactic sugar is that I
think these more architectural issues are the work that really needs
doing, and this is where I'd really like to work with someone if
Ximian is going to pay people to hack on the config system.

OK, peace out.
Havoc