Re: GConf vs. bonobo-config

[Colm Smyth <Colm Smyth Sun COM>]

There have been several lengthy debates on the merits of bonobo-conf/config
over GConf and vice-versa (look for "bonobo-conf" or "corba_any" in
the February and March gconf-list archives if you would like to see
where this discussion might go).

Bonobo-config offers a simplified API to save/restore structured
configuration data, but it is has several significant disadvantages.

The main one is that when writing to GConf, it writes structured data
into a XML document and saves it as a single string; this means
  + it can't be easily edited using gconftool command-line or gconfedit GUI
  + it is highly sensitive to version upgrade changes; adding an attribute
    to a structure is sufficient to make a user's configuration data
    invalid and inaccessible

I would be happy to use Bonobo-config if it was able to store data using
the native scheme supported by GConf, which would allow it to take
advantage of GConf features:

- XML schema language
- existing *command-line tool* to edit GConf configuration database
- completely generic GConf GUI; can use the XML schema to provide
  asstistance to the user while editing

I don't want to see a religious war when we could be making GNOME
a better desktop; I'd like to propose a solution.

The main problem again is that Bonobo-config writes a structure
into an XML document and saves it as a (long) string under a single
GConf key. The solution is for Bonobo-config to write each
attribute as a separate key and to take advantage (where possible)
of GConf data-typing. The Bonobo-config API can always build the
XML document from the underlying individual settings when required.

GConf's schema mechanism is key-based; we could gain some benefits
from a schema that also supports structures. Such a schema could 
help to define the mapping from PropertyBag to (relative) GConf keys,
which provides a level of backward compatibilty.

Havoc, Dietmar and I tried to hash the GConf/Bonobo-config question
out before on gconf-list; let's try one more time and see if we can
find a way to make it work for everyone, maybe based on the solution
I've suggested.

Colm.

>Delivered-To: gnome-components-list gnome org
>From: Dietmar Maurer <dietmar ximian com>
>X-Accept-Language: en
>MIME-Version: 1.0
>To: Havoc Pennington <hp redhat com>, Jody Goldberg <jgoldberg home com>, gnome-2-0-list gnome org, gconf-list gnome org, gnome-components-list gnome org
>Subject: Re: GConf vs. bonobo-config
>Content-Transfer-Encoding: 7bit
>
>Dietmar Maurer wrote:
>
>> 1.) Which client side API should we use, either:
>>
>>         - GConf client API or
>
>Disadvantages:
>
>    - a C API, which needs to be wrapped for all scripting languages
>    - it not a standard interface, as opposed to the PropertyBag/Event
>source interface:
>        * no code reuse
>        * you have to learn two different interface (bonobo and gconf)
>    - not able to handle CORBA_any
>    - exposes some backend internals, namely the "schema" thing.
>
>>         - The bonobo API (PropertyBag/EventSource/Monikers)
>
>    none of the above disadvantages ;-)
>
>- Dietmar
>
>
>_______________________________________________
>gnome-components-list mailing list
>gnome-components-list gnome org
>http://mail.gnome.org/mailman/listinfo/gnome-components-list