GConf and bonobo-conf

[Havoc Pennington <hp redhat com>]

Hi,

People are asking me about this "bonobo-conf" thing mentioned in
Miguel's gnome-libs blue sky web page, so I'll clarify what's up
briefly. I think discussion of the topic may have been in private
mail, it has been discussed and IMHO resolved.

There are two issues. 

Issue #1
===

A Bonobo interface to GConf; this is a great idea, I don't have a
problem with it. So bonobo-conf is that. My only objection is if the
Bonobo interface sacrifices usability issues that GConf attempts to
resolve. These are mostly to do with system administrators, but also
with users that want to do per-display, per-session,
etc. configuration. Anyhow, the GConf goal of system manageability
should not be sacrificed.

I did object to one aspect of this. Miguel wanted to do bonobo-conf
_instead_ of the GConf C API, i.e. talk to gconfd directly with
bonobo-conf. I rejected this patch and insisted that bonobo-conf be
implemented as a wrapper around the C API, for the following reasons:

 a) we were in an API freeze, and once we aren't, we need to 
    support the C API for backward compat. So the C API 
    can't be removed.

 b) the C client library contains substantial logic; I don't want 
    to maintain two copies of it.

 c) the very existence of gconfd and the CORBA interface to it is 
    currently abstracted. I do not want to give up this abstraction 
    layer. I think it may be worthwhile in the future to 
    have GConf talk directly to an LDAP server instead of gconfd; 
    it may also be useful to have it talk directly to just a flat 
    file, for embedded systems.

 d) the efficiency gain from bypassing the current client library is
    negligible. Efficiency is the only argument I heard for why 
    bonobo-conf can't be implemented in terms of the C API.

 e) if people have time to hack GConf, or if I'm going to spend time
    on patches for it, there are far more important features than
    providing a different syntax for the API.

 f) lots of people will simply prefer the C API, it already exists,
    I haven't heard a reason why it's hurting anything. For those 
    who like a Bonobo API better, they can use the Bonobo API 
    and never know the difference.

 g) there are situations where it's useful to avoid the Bonobo 
    dependency and still use GConf.

 h) we have documentation, regression tests, etc. for the C client 
    API, gconftool is implemented in terms of it, etc. Documenting, 
    testing, and stabilizing the Bonobo API to the same degree would 
    in my opinion require at least a month of effort; the bonobo-conf
    patch did not include this effort.

Anyhow, the "pros" column contained "tiny efficiency gain that hasn't
been profiled or shown to be a problem" and the "cons" column
contained a) thru h). Therefore I rejected the patch to implement
bonobo-conf by talking to gconfd directly, and requested that
bonobo-conf wrap the GConf C interface instead of replacing it. I
consider the matter closed unless a lot of the just-mentioned facts
change.

So bonobo-conf will exist if someone implements it, but the GConf C
API will not be deprecated and will continue to be supported. If it
turns out that no one is using the C API, then we can get rid of it
sometime, but I don't think that will happen.


Issue #2
===

The second issue is structured data storage in GConf. That is, right
now GConf only allows fairly primitive types to live at a key; ints,
floats, lists, pairs. You might want something more like a C struct,
or more like an XML document.

This feature was deliberately omitted from GConf 1.0 because it
complicates the implementation substantially, the right API is not
clear, and there was not time to do it while still delivering a
stable, high-quality library. It's something I would like to see a
solution to. I don't know the right solution; it's a hard problem.
Miguel's suggestion is CORBA_any, which may be right, but it's by no
means obvious to me that it is, and in any case it was proposed
post-API-freeze.

There are reasonably good workarounds to the problem with GConf 1.0,
including:

 - store an XML document as a string at some key
 - store a serialized CORBA_any as a string; bonobo-conf
   could do this transparently
 - don't use GConf to store documents and other large data; it's 
   just intended for the same purpose as gnome_config_* really, 
   and you wouldn't try to store some giant data blob 
   in gnome_config_* either. You could instead store e.g. 
   a moniker or filename pointing to your structured data in GConf.
 - use a directory full of keys as a struct
 - use gconf_unique_key() to get unique keys, and use a directory 
   full of those if you need a list of lists, or a directory full 
   of uniquely-named directories if you need a list of "structs"
 - write serializer convenience functions for common types such 
   as GdkColor. Have the format for these standardized 
   by the GConf documentation. (i.e. the docs could suggest
   that any color value be stored as a 24-bit RGB integer). 

Some issues to consider when proposing a solution:

 - notification of changed values has to be fast, and it sends 
   the contents of the value over the wire. Thus, 
   GConf values really can't be large.
 - values must be documented well, and editable via a generic 
   regedit-style tool. So you would expect fields in a struct-like
   object to be documented. Binary blobs that sysadmins can't 
   do anything with are to be discouraged.
 - you don't want all the settings for your app stored in some huge 
   struct; that defeats the ability of users and admins to separate
   those settings so that some are per-workgroup, some per-session, 
   and so on.
 - I question whether CORBA_any is the right answer in part because it
   would be the only use of CORBA in the GConf API, and some apps may
   not be using CORBA. I think an XML-based solution might be more
   least-common-denominator.
 - I'd like to keep implementation of apps and of the GConf
   admin/editor tool reasonably simple, so it gets done.
 - I'd like to keep the implementation of GConf itself reasonably 
   simple, for speed/stability/robustness reasons.
 - I do think GConf can afford to be less scalable in this area than
   something like LDAP; desktop apps simply aren't all that demanding,
   and GConf is really end-user-app-specific. It's not intended for
   system or server configuration. It's just intended to store user
   preferences.

There are other issues, I haven't thought it through fully, and that's
why you don't see a solution in GConf. Given the existence of
workarounds that are good enough in practice (after all,
gnome_config_* has been OK in practice), I don't see any sense in
tossing in a patch until we have some good experience with GConf and
have a better idea what the right thing to do might be.

I really haven't seen a good discussion of the issues from anyone, and
certainly I don't want to hear whinging about me not taking a
CORBA_any patch until such a discussion appears.

So, that's the deal, I hope that it clears up questions about
bonobo-conf.


In general, I think the following issues are more important and should
be the focus of work on GConf, rather than the above two issues:

 - transaction support (make GConfChangeSet atomic)
 - the GUI admin tool
 - working solution to per-session, per-display, etc. settings
 - a network backend such as LDAP
 - improved test suite coverage
 - finished documentation
 - getting support for GConf in applications
 - keeping things simple enough to use and implement

If someone is willing to hack on GConf for GNOME 2, I would encourage
them to tackle some of these issues.  I'm not sure we should worry too
much about replacing or extending the API before actual user-visible
features have even been deployed.

Havoc