Re: GConf and bonobo-conf

[Colm Smyth <Colm Smyth ireland sun com>]

I'm very much in favour of API's exported via CORBA, which gives all the
advantages you mentioned; I'm simply not in favour of adding CORBA_Any
to GConf's current data model.

Colm.

>To: Colm Smyth <Colm Smyth ireland sun com>
>Cc: michael ximian com, dietmar maurer-it com, hp redhat com, 
gconf-list gnome org
>Subject: Re: GConf and bonobo-conf
>From: Miguel de Icaza <miguel ximian com>
>
>
>> I don't want to invest more time making the case against introducing
>> a structured-storage mechanism in GConf when the API wasn't designed
>> for that; if it doesn't require changing GConf internally, then
>> it's a case of caveat hacker - use the structured storage knowing
>> that it makes your app harder to evolve in a way that puts a value
>> on the user's configuration data.
>
>Well, as we claimed before, we are using the GConf "engine" to store
>values and notify people who have requested to be notified of changes,
>but we do not even need to use the existing GConf API.
>
>Our current approach is based on monikers, so you do:
>
>	use Bonobo;
>	init Bonobo;
>	
>	bag = Bonobo->get_object ("config:key", "Bonobo/PropertyBag");
>	$property = $bag->getProperty ("Email");
>	print "Email: " . $property->getValue ();
>
>Notice that this is a working piece of code in Perl/Gtk, no code
>wrapping was required, it is just using the stock Bonobo wrapper and
>uses the moniker system to resolve to an interface that you can use.
>
>The beauty of this scheme is that the API is defined in terms of the
>CORBA IDL for PropertyBag and Property, and it is available across all
>languages with Bonobo/CORBA support.
>
>One API less to be wrapped.
>
>Miguel.