Re: GConf and bonobo-conf

[Dietmar Maurer <dietmar ximian com>]

"Colm Smyth [RU-Ireland]" wrote:

> One issue I have raised previously with CORBA_Any support is that
> it has the potential to create configuration versioning issues.
>
> The goal of CORBA_Any support is to help developers by allowing
> them to store arbitrary structures in the configuration store.
> These structures may easily change, leading to incompatibilities
> if there is an attempt to restore the information from the store
> (CORBA_Any support would require perfect binary restoration).

bonobo-conf is able to read any CORBA_Any. So you can simply
check if the value is of the right type (CORBA_TypeCode_equal()).

Sure, you can't use the data if you don't understand the contents of
the type. So we should never make binary incompatible changes to
types stored in the database. One solution would be to add a version
to the type name, such as GdkColor_1_0. Or it is maybe possible to
use the repo_id version somehow?

Anyway, you always have a problem if you change the type (=content)
of the data stored in the database, and you need to define a smart upgrade
path - even if you decompose the values as suggested. You can even
make a system that tries to read incompatible types and restores as much
data as possible based on simple heuristics - everything else is filled
with default values. Well, I don't suggest this approach but such a system
would have exactly the same semantics as decomposing the values. Both
systems does not solve the upgrade problem. Lets say we want to store
colors:

struct Color {
    int r,g,b;
}

We then decide to store them as:

struct Color {
    int c,m,y,k;
}

So what is the advantage of decomposition in that case? The upgrade
problem always exists.

> I think it makes more sense to think about what configuration
> data you want to store and how you want to store it.

We do not suggest to store everything as complex type. You can
still use types like int, string, boolean even if you use CORBA_any ;-)

> If you really want to throw arbitrary data into GConf, there is
> nothing to stop you; you just need to encode your CORBA_Any as
> a string and use the GConf string storage. You just need to remember
> that you can't evolve your structures; if a user uses a GNOME 2.0
> application and their app stores some configuration data, that user
> will want to continue to use that configuration even if they later
> upgrade to GNOME 2.1 say.

See above.

> I'm much more in favour of de-composing structures down into
> elementary configuration data items as these can be more robustly
> restored. This is an essential difference that could be compared
> to the difference between say serializing a Java object as meta-data-rich
> binary data and doing the same thing but writing out to XML. The XML
> is simply a more evolve-able data store; so is a collection of primitive
> configuration data items stored in GConf.

We already save CORBA_any as nice XML in bonobo-conf.

- Dietmar


_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers