Re: GConf and bonobo-conf

[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.

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.

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

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.


Miguel.