Re: GConf and bonobo-conf
- From: Miguel de Icaza <miguel ximian 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
- Date: 22 Feb 2001 14:37:12 -0500
> 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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]