Re: GConf and bonobo-conf

[Michael Meeks <michael ximian com>]

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.

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

> 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
> >bug-free.
> 
> 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
anything ?

	Regards,

		Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot