Re: GConf and bonobo-conf

[Colm Smyth <Colm Smyth ireland sun com>]

>Delivered-To: gconf-list gnome org
>From: 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?

Bonobo-conf can naturally read and write any CORBA_Any because it
doesn't care about type or content.  If GNOME applications can write
version-dependent binary information into GConf, users will have a lot
of difficulty upgrading.  Since GNOME development is fast and we want
to keep adding new features, we don't want to be stuck with
version-compatibility issues, or worse we don't want to write specific
code to migrate users from one application version to the next!

It also means that the data is unreadable by other applications
unless they use the same data-structure (and the same version).

If you write configuration data as primitive values, you get the
following advantages:

- application transparency; other applications can easily read and
  write the data
- easier upgrade; most changes to data structures are additions and
  this creates no upgrade problems as new applications can continue
  to read the existing configuration information
- easy to edit; users will be able to use the GConf tools to change values;
  gconftool can display and edit values, and the upcoming Gtk+-based gconfedit
  application will also be able to browse, display and edit GConf.

Writing binary data (even with type information) into GConf eliminates many
of the advantages of GConf. It doesn't even reduce the amount of code
you need to write; if you are even a little bit concerned about giving
users a great experience with GNOME software, you would have to write
more code to migrate users to the next version of an application than
you would to just write the essential GConf data-types in the first
place.

I'm delighted to hear that you use XML as a storage encoding, but
applications can't benefit from the flexibility of XML as your interface
is CORBA_Any and so apps will expect a fixed data-structure. If the
application used XML directly, it could interpret the configuration
data and handle version-upgrade in a robust way.

I would like to propose a mechanism that allows a DOM-based interface to
GConf; I believe this is equally powerful but more flexible. I mentioned
this briefly to Miguel recently at a conference. A DOM interface to GConf
would allow higher-performance access to GConf and a low impedance
mismatch between application configuration needs and the GConf interface.

I'll send some more info early next week; I'd welcome input from any users 
of GConf whether you agree or disagree with what I've said.

Colm.

>
>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
>
>
>_______________________________________________
>gconf-list mailing list
>gconf-list gnome org
>http://mail.gnome.org/mailman/listinfo/gconf-list


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