Re: GConf and bonobo-conf
- From: Colm Smyth <Colm Smyth ireland sun com>
- To: Colm Smyth ireland sun com, miguel ximian com
- Cc: michael ximian com, dietmar maurer-it com, hp redhat com, gconf-list gnome org
- Subject: Re: GConf and bonobo-conf
- Date: Mon, 26 Feb 2001 09:38:57 +0000 (GMT)
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.
>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.
] [Thread Prev