GConf vs. bonobo-config

[Havoc Pennington <hp redhat com>]

Martin Baulig <martin home-of-linux org> writes: 
> I'm not saying that we should remove it, I'm just saying that you don't need
> it to compile GNOME 2. If you want to use GConf in your application, then your
> application depends on GConf, but I don't see why a library should depend on
> something which it does not use.

The point is that GConf is one of the libraries we're trying to
stabilize for the end of July. We aren't porting Nautilus to
bonobo-config before GNOME 2.

Another point is that moving from GConf to bonobo-config has NEVER
been discussed in any forum that I've seen. Nautilus uses GConf,
George is coding up Pong to use with GConf, GConf is the current plan
for config storage. Bonobo guys have been hacking on their thing, but
replacing GConf as the current GNOME solution needs to be discussed
and evaluated. This has NOT happened. Well, the only discussion has
been on gconf-list and it was hardly concluded in bonobo-config's
favor.

And don't say send patches or claim you get to decide since you're
doing the work, because I'd already done the "GConf-ification" of
gnome-libs, you undid that work.

I haven't been complaining about bonobo-config much because I thought
we were using it as a GConf wrapper. However now it turns out that
isn't true, that we are using the bonobo-config flat XML file.  I'm
not at all convinced that's a good idea.

> What's so special about this desktop-wide notification stuff that bonobo-config
> cannot do this ?
> 
> Desktop-wide notification means that an app can get a callback if some config
> value changes, even if another application changed it, right ?
> 
> This already works in bonobo-config with any backend which is not a shared
> library.

With code that's O(n) in the number of listeners, among other issues.
And a completely unscalable XML backend.

GConf scales to lots of listeners and its XML backend scales to lots
of data. It has a meaningful test suite that passes.  I never get any
bug reports on it (except that one where OAF spawns two gconfd copies,
and the one where OAF doesn't spawn any gconfd copies at all and fails
to report an error - both are OAF bugs). Well, I also get reports
caused by people blowing away files and running "killall" left and
right until they get OAF and GConf both really confused. Though GConf
is remarkably robust against this and most of the time can actually
respawn over a SIGKILL while maintaining exactly the same
client-visible state, including maintaining the listener list. This
mostly only breaks when oafd is also killed.

Also, right now this is totally broken in libgnome:

        cdata->desktop_config_moniker_id = gnome_program_install_property
                (klass, libbonobo_get_property, libbonobo_set_property,
                 g_param_spec_string (GNOME_PARAM_DESKTOP_CONFIG_MONIKER, NULL, NULL,
                                      "xmldb:" LIBGNOME_SYSCONFDIR "/gnome-2.0/gnome-desktop.xmldb",
                                      (G_PARAM_READABLE | G_PARAM_WRITABLE |
                                       G_PARAM_CONSTRUCT_ONLY)));

The database needs to be a database stack, to allow system defaults,
overridden by user settings, overridden by mandatory systemwide
overrides. GConf already handles this. Notification in this case is
quite tricky, especially if you want it to be fast.

I don't think BonoboConfig is fundamentally bad, it is more or less
the same thing as GConf made "Bonobo-native" instead of "G*-native".
But I don't think it's remotely as well-tested, documented, or
thought-through as GConf at this point in time. I can't even find in
the docs how to install a default value, other than hardcoding a
"defaults" database in my app and then falling back to that database
if the "non-default" database has nothing set. The database stack
needs to be a systemwide config setting along the lines of
/etc/gconf/path.

But I'd like an answer to this:

     One of the giant points of GConf is a single config database
     stack containing all settings for all apps. Because that's what 
     makes it possible to do system administration of prefs in a sane
     way. The only reason GConf lets you access non-default databases
     is for admin tools, apps should NEVER do this.

And that brings us to:

     We need a single config database stack, so it is Very Evil if we
     have some apps using the GConf stack and some using the
     bonobo-config stack. And the only way to ensure that is to use 
     bonobo-config as a GConf wrapper, or use GConf as a bonobo-config 
     wrapper. So we do need to decide between these technologies.

I just don't think we should fuck over sysadmins and throw away all
the testing (and test suite, and careful design) of GConf for an
experimental bonobo-config solution. Let's use what Nautilus is using
and what we were planning to use.

Dietmar's "critique of GConf" in his docs is nothing but bullshit;
it's whining about syntactic sugar. Using bonobo-config as a wrapper
for GConf solves that problem. This has been extensively pointed out
on gconf-list.

Whereas the criticisms I've made of bonobo-config as a standalone
non-wrapper are substantive real issues that have to do with
stability, maintenance, and features that sysadmins see. Because gee,
I actually thought about issues other than what type system
infrastructure and naming convention we are using this week.

Again, I have no problem with bonobo-config wrapping GConf, but if
people are going to try to take GConf out of the picture, this needs
further discussion. It may make sense sometime, but it doesn't make
sense for GNOME 2 IMHO.

Havoc