Re: GConf and bonobo-conf

[Colm Smyth <Colm Smyth ireland sun com>]

>To: Colm Smyth <Colm Smyth ireland sun com>
>Cc: michael ximian com, dietmar maurer-it com, hp redhat com, 
gconf-list gnome org
>Subject: Re: GConf and bonobo-conf
>From: Miguel de Icaza <miguel ximian com>
>
>
>> That means that all apps have to work with CORBA_Any; 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? 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) or parse the CORBA_Any manually (not easy code to write)
>> using knowledge of what you intended the structure to be.
>
>As I said before, if you change the format of your configuration data,
>you should use a different key.  So writing code that knows about the
>format of the content of a key is perfectly fine.

I think everyone in this discussion could prefix everything they are
saying now with "As I said before"; we've gone around in circles a
few times; occasionally we throw in a tangential comment.

I'll just say this one more time and then I'm stepping off this
particular roundabout:  * structures increase the risk of a new version
of your application being unable to use the data of a previous
version compared to atomic keys (see reasons earlier) *

Changing the key doesn't change the fact that when a user upgrades,
they may find bits of their configuration mysteriously 'dropping
out'.

>In GConf for instance, you are *supposed* to write:
>
>	int a;
>
>	a = gconf_client_get_int (client, key, err);
>
>	if (error_in_transaction (&err)){
>		deal_with_it ();
>	}
>
>This would account for dealing with mismatches on your data types from
>version to version.

Error-handling is one thing; being able to respond to planned changes that
a developer made when evolving their application's configuration storage
is quite different.  Structures increase the risk of an incompatible
change and they increase the amount of data that is lost; it's as
simple as that.

>This being so common has lead to things like the nautilus_ wrappers
>for gconf.  

GConf really isn't all bad; there are some uniquely good things about 
it (ok, maybe just one thing), but there is a difference between
changing the API to make it better and altering the fundamental
data model in a way that increases the risk of version breakage.

>But in practice people are coding *assuming* that key data will not
>change.  All the code in gnome-libs HEAD for instance assumes this --
>I would claim this is not defensive programming and it is buggy -- but
>it shows that people are *assuming* that the content of their keys is
>going to be kept static.

I haven't looked at everything that people are doing in terms of using
GConf, but I agree there are some aspects of GConf's API that make it
difficult to handle some kinds of changes to applications.

I'd like to suggest that I come back to this mailing list with
a specific proposal for some new changes GConf API; the existence of the
nautilus_wrappers is a good reason to be aware that there is a problem
and I have some ideas on how to solve them.

I don't want to invest more time making the case against introducing
a structured-storage mechanism in GConf when the API wasn't designed
for that; if it doesn't require changing GConf internally, then
it's a case of caveat hacker - use the structured storage knowing
that it makes your app harder to evolve in a way that puts a value
on the user's configuration data.

I won't write the proposal on this thread because I suspect many
people have stopped reading it by now ;)  I would welcome feedback
on my proposal (I'll find some time to write it later today).

Thanks for a provocative discussion!

Colm.

>
>Miguel.