Re: GConf vs. bonobo-config

[Bob Smith <bob thestuff net>]

Couldnt the CORBA_ANY problem be solved with some kinda idl compiler to
turn idl values into gconf values? take a corba struct and convert it
into code to load/save that kind of struct in gconf as key/value pairs?
then it has the advantage of easy to use for the developer, will support
a generic gui editing utility, and wont have versioning problems.

On 18 Jun 2001 13:33:24 +0100, Colm Smyth wrote:
> 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
> 
> 
> _______________________________________________
> gconf-list mailing list
> gconf-list gnome org
> http://mail.gnome.org/mailman/listinfo/gconf-list
>