Re: GConf design goals.

[Byron Ellacott <bje apnic net>]

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.  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. :)

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