Re: GConf and bonobo-conf
- From: Michael Meeks <michael ximian com>
- To: Colm Smyth <Colm Smyth ireland sun com>
- Cc: dietmar maurer-it com, hp redhat com, gconf-list gnome org
- Subject: Re: GConf and bonobo-conf
- Date: Wed, 21 Feb 2001 09:13:36 -0500 (EST)
On Wed, 21 Feb 2001, Colm Smyth wrote:
> Not just the API, the underlying data model is at fault.
Good, now we can engage :-)
> As I've mentioned before, building CORBA_Any into the API doesn't help
> other applications interpret the data, access/modify discrete data
> elements, or deal with data versioning.
Perhaps, but it in no way hinders them - this is my thesis and I'm
sticking to it.
> The DOM is just the API, the data model is XML - self-describing data.
> GConf's data model is a hierarchy of primitive values.
We agree that XML is a nice representation - not convinced by
any merits of 'self description' though.
> That means that all apps have to work with CORBA_Any
> how do I write an app to interpret this data unless I have access to
> the details of the data-structure that the owning app used to write
That is encoded into the Any. Please read
ORBit/src/orb/corba_any_type.h, you will see the Any contains not only the
data, but also complete 'self describing' TypeCode information.
> I'd have to either include your header file (creating a dependency so
> that every time you change that data-structure in your application, I
> have to re-build mine)
Then please read ORBit/src/orb/dynany.h, however to an extent you
are right, if you have a tight contract between two apps they talk through
an interface, and this should be specified in IDL somewhere.
> or parse the CORBA_Any manually (not easy code to write) using
> knowledge of what you intended the structure to be.
You have complete knowledge in the TypeCode, and there is no need
to parse it yourself.
> You seem to be suggesting that I should not use the CORBA_Any
> interface but instead manually interpret the stored XML. I don't think
> this requires less code than storing the individual data elements.
Ok; perhaps I explained this really badly, but you repeat this
question below with a challenge to demonstrate with code how simple it is
to write this mapping function. On the contrary, I will draw you my single
API that works for all CORBA_Any's no matter how complex, and then
sketch out how the equivilant structural change works in GConf land:
CORBA_any *config_engine_get_value (const char *path,
Where the combination of the original TypeCode that was stored
into this path and the new 'desired_type' TypeCode is essentialy the
re-usable representation of the human-compiled gconf code that would do
if (gconf_key_exists ("/old/key/a"))
s->a = gconf_get_key_as_long ("/old/key/a");
s->a = 276;
> Maybe you could write some example code that uses the CORBA_Any
> interface to write a rich data-structure in the way you intend and
> then write the code to interpret that data when the version of the
> data-structure that was written is not the version you expect
You know the typecode of the version you expect - this is given
and is no different to having compiled in knowledge - NB. for super
complicated cases, of course you can switch on the Any's TypeCode. The
implementation of config_engine_get_value has to be written once, and is
non-trivial but non-impossible - a day or two's work.
> (and so you have to manually parse the stored data and map the
> individual data elements to the new structure). If it's as easy as you
> suggest, that wouldn't take long and would be very convincing proof.
I don't want to manualy parse anything really, I just want to cast
the any to a struct of the type I am interested in, this would allow me to
do this trivialy.
> Well no, to be complete we have to write the code once for every time
> a data-structure changes.
Why ? or put another way, in what way is this true, that does not
invalidate the argument that this change would not be neccessary for
gconf's key / value setup ?
> To be really complete, we have to handle bi-directional conversion
> from every version to every other version.
And the above method will do that - clearly in a lossy way, but no
less lossy than the current gconf alternative.
> If the underlying data model could handle additions transparently,
> then most version-related issues could be handled. The main issue is
> ensuring that the data has the same meaning (e.g. storing an
> enumerated value is basically fine, but if you like to keep your enum
> members in alphabetic order, the next time you add a new member you
> are likely to break old configuration data). This issue is true
> whether you store your data as a BLOB (from the perspective of the
> data store) or as discrete addressable data elements.
But interestingly not when you store as a CORBA_Any since the
enumeration's symbolic names are stored in the typecode data.
> Michael, I'm really on your side; I would love to be able to easily
> store rich data in GNOME's configuration system, but there is a
> mis-match in the data model. If we add the bonobo-conf feature to
> GConf, it becomes very difficult to persuade developers that they
> should only use it for configuration data structures that will not
> change (because handling multiple versions of the data is hard).
Ahh :-) but you see, I think we agree far more than we think. You
see, I know this versioning issue is a red herring, and I think we have a
lot of common ground.
I too would like to be able to address sub-members of my structure
by key, however I would like to be able to address the aggregate as a
structure / union or whatever is most appropriate for me.
This militates in favour of a nice XML storage mechanism, and some
small bits of clever mapping code XML <-> CORBA_Any.
> Someone is sure to suggest that we version the configuration data
But not me :-)
> > This is shared code, written once in gconf / bonobo, yes it is
> >relatively non-trivial, but it is centraly maintained and can be made
> Similar code is needed for every data-structure that changes, each
> time it changes.
Nope - only with GConf.
> 1. Fix GConf's APIs to be more efficient to use and run
> 2. Start work defining a rich configuration API for GNOME 3.0 that
> Note that XConf internally would probably use a decorated DOM
> as an application-side cache, so the _dom_create() API would be
> trivial (just incrementing an internal reference count).
If I had ever seen a truly lightweight DOM implementation I would
be very pleased, we will clearly have to implement one.
> Given the proposals I've given earlier in this thread for how we could
> improve GConf to solve some of the most urgent current issues, do you
> think you could wait for GNOME 3.0 (maybe 1.5-3 years out) for XConf?
Well :-) Not really, when we can do everything we need to in
bonobo-conf now, and the only people to suffer will be the people who use
the gconf - C API.
Anyway, perhaps you missed the CORBA_TypeCode on the Any, and the
serialization of that - it's what it looks like anyway, so does that alter
mmeeks gnu org <><, Pseudo Engineer, itinerant idiot
] [Thread Prev