Re: GConf and bonobo-conf

[Andrae Muys <amuys shortech com au>]

Miguel de Icaza wrote:
> 
> > (In the above case, I'd also be strongly in favour of renaming the EMail
> > field when you reassign the meaning of its contents; the old field, if
> > its values are no longer meaningful, can be safely ignored.)
> 
> Yes, that is exactly the point: if you change the meaning, the
> content, or any other part of the contract, then you have to use a new
> key, and provide a migration mechanism.
> 
Unless however your application didn't make use of the EMail field, but
did make use of the IMAPServer field in the same directory (say
preferences/messaging/email/) I would be unaffected by the change. 
However if this was stored as a compound-type, every application that
used any of a users email preferences would now have to provide
migration scripts or fail.

This difference is even more stark when you consider added
functionality.  Consider an application that adds support of MS-Express
servers.  Now an additional server preference needs to be added.  If we
store the data as fundamental types accessed by key, regardless of any
syntactic sugar that simplifies the API, no changes are required. 
However if we permit developers (ie *me*) to store compound-types
directly, then they (ie. *I*) will use them, and then this change would
require all applications which use *any* email-messaging preferences to
provide migration scripts.

Worse, the scripts themselves will be harder to write, as the
compound-type will need to be deconstructed, modified, reconstructed and
stored.  This will be an interesting scripting challange to achieve in a
shell-script.

One thing that does come out of this is the possible desire to have a
"deprecated" flag in the schema, which could be used to flag use of
"deprecated" key/value pairs.

Andrae Muys