Re: GConf design goals.

[Colm Smyth <Colm Smyth Sun COM>]

>Delivered-To: gconf-list gnome org
>From: Byron Ellacott <bje apnic net>
>X-Sender: bje hadrian
>To: Colm Smyth <Colm Smyth ireland sun com>
>Cc: gconf-list gnome org
>Subject: Re: GConf design goals.
>MIME-Version: 1.0
>X-BeenThere: gconf-list gnome org
>X-Loop: gconf-list gnome org
>X-Mailman-Version: 2.0beta5
>List-Id: Discussion of the GConf library <gconf-list.gnome.org>
>
>On Thu, 1 Mar 2001, Colm Smyth wrote:
>
>> 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.
>
>This breaks when two applications decide to add a third item to the 
list,
>independently of each other, or if the original app, unaware of the 
second
>app, decides to say that the items from 3+ are masks to not use a proxy
>for, things will break.

The 'one application' I referred to should be the 'owner' of the specific
piece of configuration data; the other applications are consumers of
this data, but they may not have been updated to know about the
extended configuration. Actually an older version of the same application
may also be an example of an 'other application'.

>  In this case, I'd probably use a pair for (host,
>port) and a vector for (noproxy, noproxy, ...), since these are
>semantically stable.  In cases where a pair doesn't work, and I really
>wanted low namespace, I'd use a subpath proxies/host proxies/port
>proxies/noproxy, or just .../proxy-host .../proxy-port.  This may be
>tangential, but it does show how the choices you make for your
>configuration data are quite important (granted, you were just giving an
>example, no reflection on you. :)

Making a choice about how to store configuration is important for the
longevity of that data and the ease with which it may be shared with
other data; that is the crux of why I have been arguing (repeatedly)
against structures in the configuration data.  They are a convenience
feature that is likely to break forward compatibility of configuration
data and make the data implicit rather than explicit at the level of the
GConf API.

Deciding what features of an application should be configurable
and how that configuration should be stored requires thoughtful
consideration. It is different from deciding how to code an
algorithm in an application because the configuration is external
to the program - it is a public 'interface' to the application
that should support forward compatibility.

Colm.

>If a setting is in /apps/<appname>/, I think it would be impolite for
>another app to modify the meaning of the data there, either by changing
>what a value contains, or by adding a key.  I'd like to see this 
enforced
>by having schemas for paths describing what keys are valid, and schemas
>for each key, describing the data for a human; it can then be 
discouraged
>to go against a schema, or to modify a schema you didn't create, or to
>modify a path schema in any way except adding nodes, or to modify a key
>schema except to say it is deprecated.
>
>Now, I haven't thought this through a whole lot, so the above paragraph 
is
>probably fairly patchy, and may not be feasible to implement, just
>throwing out a general thought.
>
>-- 
>bje
>
>
>_______________________________________________
>gconf-list mailing list
>gconf-list gnome org
>http://mail.gnome.org/mailman/listinfo/gconf-list