Re: GConf design goals.

[Colm Smyth <Colm Smyth ireland sun com>]

This is a good question, it should help me to show some of the
special pitfalls with structures vs. the existing GConf data-types.

Any aggregate (e.g. a list, pair, array, structure) shares some of
the fragility of structures, but it is nowhere near as bad:

- a list can still be processed by all applications that expect a list
- a GConf list is homogeneous (same data-type)
- if the use of the content of the list remains the same, then adding
  an extra element does not confuse any readers because they can simply
  ignore it; to be robust, apps should write any data in a list or pair
  that they do not understand and only update the elements that they
  do know about

A pair is really fine because it is a 'fixed' size list.

An example: 

If a list is used to store say a list of URL's, then it is not a
structure, it is simply a multiple instance value. 

If it is used to store a http proxy hostname followed by a proxy port
number (as a string), then it is being used as a pseudo-structure but so
long as applications treat it as a list and use just the first and second
elements of the list, it doesn't matter if one application appends a
third element for it's own purposes so long as any applications that
*write* the list will preserve any "unknown" elements.

Even if I add an element to a list, all clients of GConf can continue
to work with it because it hasn't changed data-type and it is
readily accessible via the GConf API.

If you change the data-type of the list or change the order of
semantically different elements, you have broken your configuration
data. By comparison, no change to a structure can be made without
breakage; you can't even add a data member.

Colm.

>To: Colm Smyth <Colm Smyth ireland sun com>
>Cc: gconf-list gnome org, amuys shortech com au
>Subject: Re: GConf design goals.
>From: Miguel de Icaza <miguel ximian com>
>
>
>> Thanks for your support, the bonobo-conf thread has become a little
>> weary but it's nice to know that other developers see some of the 
issues
>> with this proposed feature.
>
>Well, GConf does support lists and it does support pairs which have
>all the bad attributes of structures.  So how are these any better
>than Anys?