Re: GConf vs. bonobo-config

[Colm Smyth <Colm Smyth Sun COM>]

CORBA_Any is just a way to serialize and de-serialize values; as it
was primarily intended to be used by generated code (stubs and skeletons),
it doesn't include attribute names; this also makes it more compact.

To do an effective mapping, it must be possible to determine the
name of each individual attribute; saving the name would improve
both bonobo-config's XML serialization and GConf mapping.

The PropertyBag interface supports names for attributes so this
should be possible.

Colm.

>Subject: Re: GConf vs. bonobo-config
>From: Bob Smith <bob thestuff net>
>To: Colm Smyth <Colm Smyth Sun COM>
>Cc: hp redhat com, jgoldberg home com, gnome-2-0-list gnome org, gconf-list gnome org, gnome-components-list gnome org, dietmar ximian com
>Content-Transfer-Encoding: 7bit
>Mime-Version: 1.0
>
>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
>> 
>
>