Re: GConf and bonobo-conf

[Colm Smyth <Colm Smyth ireland sun com>]

Michael,

This has got to be my last response to this thread, for better or for worse!

>Delivered-To: gconf-list gnome org
>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
>MIME-Version: 1.0
>X-BeenThere: gconf-list gnome org
>X-Loop: gconf-list gnome org
>X-Mailman-Version: 2.0beta5
>List-Id: Discussion of the GConf library <gconf-list.gnome.org>
>
>
>Hi Colm,
>
>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.

If you offer a kid the choice of
a) meat and vegetables 
b) ice cream

and tell them that they have to stick with their choice for 5 years,
they won't wait for the punchline, they're already looking for the
chocolate sauce.

I'm not comparing developers to kids but in some respects a developer
is opportunistic about making choices. Any developer who has to juggle
a lot of decisions when coding an application while still creating
features will make choices based on:
- available sample code; what can I re-use or plagiarise?
- whatever looks fastest to code

Not every developer will be able to make the time to make the right choice.
It would actually be better if developers offered fewer configuration
options with more longevity than lots of choice but the hassle of
upgrading configurations later.

You've surely heard the story about the developer who refuses to do a 100 hour
task manually but is happy to code up a tool for 99 hours to do the same thing
in an hour.  We may have already invested more time in this discussion than
would have been saved in the entire GNOME 2.0 project by coding the
serialize/deserialize code for data-structures manually!

>> 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
>
>	Correct.
>
>> 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
>> it?
>
>	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 believe I already said just that; the problem is that GConf has a model
based around primitve data-types, XML and IIOP have different
models for self-describing data that are not addressable by GConf
(remember my read/write analogy?).

>
>> 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.

Ok, so I'm partly right. Which part am I wrong about? ;)

>> 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,
>				    CORBA_TypeCode desired_type,
>				    CORBA_any     *defaults,
>			 	    CORBA_Environment *ev);
>
>	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
>this:
>
>	if (gconf_key_exists ("/old/key/a"))
>		s->a = gconf_get_key_as_long ("/old/key/a");
>	else
>		s->a = 276;
>
>	etc. etc.

Ummm, I don't see any way that you can automagically migrate data from
the old data-structure to the new one, even if the new one just contains
one more data member. The typecode doesn't help, it just lets you
know that you have migration problems, it doesn't offer a solution.

One last counter-example: if you look at Java you will
see that the original Serialization API was pretty useful but
not ideal for storing data that could continue to be used
over long periods, especially if the class changed. They
made some additions (e.g. to identify which data members should
be persisted), but it wasn't a complete solution. The later
Externalizable interface allowed more control over the
persistence and could potentially robustly handle different
versions of the data structure, but it was more work for
developers. No-one has ever suggested that Java lacked
meta-data, but it doesn't help with automatic de-Serialization
of data from another version of a data-structure.

One last suggestion: since the key advantage of of bonobo-conf is
to reduce lines of code written by developers to save configuration,
why not just write a few helper functions to save/restore common
configuration structs? These functions could be written with forward
compatibility of configuration data in mind.

Colm.