Re: GConf and bonobo-conf

[Colm Smyth <Colm Smyth ireland sun com>]

Hi Miguel,

I think you may be missing out on some points in my e-mail.

- naturally any configurable 'variable' can cause breakage if it is
  altered in terms of data-type or meaning
- a structure is more likely to be altered in a way that is not binary
  compatible because a change to any member is likely to cause breakage;
  if a structure has one member, it has the same probability of breaking
  as a primitive value. Every additional value is a multiplier for this
  base probability
- adding a member to a structure breaks access to all of the data members;
  adding a new primitive configuration variable breaks nothing (unless it
  alters the semantic of an existing configuration variable, in which case
  the addition of the variable is not really the problem)
  
There is a 'contract' for even primitive variables, it's just that
a structure can be changed in a way that doesn't break the contract
(data-type and semantic) for it's individual data members, but does break
access to those members because the structure has changed and so
it cannot be read by an application that expects to read the old structure
(the inverse problem can happen if an old app tries to read the new
structure).
  
Colm.

>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>
>
>
>> Not at all. 
>
>Colm, if you change the contract for a system setting, even if the
>type is the same, you are going to break applications.
>
>Lets picture the key "EMail" which is of type string, lets say that
>the contract states that it contains a value like this:
>
>	"enable", "disable", "forward"
>
>And then you decide to change the value contents to mean `internet
>address'.   
>
>This is just an example that any change to the contract of what a
>configuration key holds both content-wise and definition-wise will
>lead to broken applications.
>
>> Think about this; a structure (by definition) is more
>> likely to cause application breakage because it is more likely to
>> evolve. 
>
>I do not know where you got this definition from.  I do not see
>structures being defines as `A way of grouping data values that is
>likely to break'.  
>
>Now, let me show you a counter example: read, write, lseek.  Those do
>not take data structures, still for 64 bit operations you are required
>to use their 64-bit counterparts (lseek64, etc).
>
>> An application would be no longer able to read the structure
>> automatically using the CORBA_Any interface if:
>> 
>> - any data member changes
>
>Yes, and this applies to any other contract breakage.
>
>> - a member is added or deleted
>
>Ditto.
>
>> - members are re-ordered
>
>Ditto. 
>
>> An atomic configuration item is far less likely to change, so it
>> represents a more robust interface to a piece of configuration data.
>
>Not really, a breakage in the contract is still a breakage in the
>contract.  See Sun vs Microsoft.
>
>Miguel