Re: GConf and bonobo-conf

[Miguel de Icaza <miguel ximian com>]

> So in the specific case you mentioned for example, how would you
> migrate to a new version of Evolution that wanted to add or remove
> fields from those objects? At that point it seems like the convenience
> of CORBA_any would go straight downhill, you'd need to keep two
> versions of your IDL and handle both.

If you alter the data you are storing for either the CORBA_Any case or
the flattened-out version you will run into the same problem: you can
not interpret the data structures correctly.

If the key `/Application/Evolution/Layout' changed structurally, or if
your gnome-config/gconf flattened representation changed, in both
cases you have a compatibility problem.  This is not endemic to
CORBA_any.  The problem is there.

The only *correct* way of dealing with the problem is to use a
different key value for a new version.  Using the example above:

	`/Application/Evolution/Layout2'

Using Gconf core structures or a simplified string mechanism will not
address configuration changes.  Pretending that it is correct to
handle the data on incompatible upgrades is not possible.

Once we have come to terms with the idea that you *have* to use
versioned keys (just like you have to use versioned interfaces in
CORBA, or in the Linux kernel or with libc) we can look for ways of
making the life easier for users.

Making life easier to users means `You need to have importing
facilities in your code to deal with migration from version N to
version N+1'.

Miguel.