Re: GConf design goals: a summary?

[Byron Ellacott <bje apnic net>]

On Tue, 6 Mar 2001, Dietmar Maurer wrote:

Sorry for the lateness of this reply, I have been busy.

> The whole discussion always gets to the same point: If you use structure you
> have an upgrade problem. People tends to neglect the fact that the upgrade
> problem always exists. If I use CORBA_any I have strong type checking, so I
> can detect that I have an upgrade problem.

The point is not that structures *create* the problem, more that they
enhance the problem - this is what I mean by brittle.  If you have one
item of data with some probability that it will be broken by upgrade, then
that's the whole story.  If you group 5 items together, then the
probability that all 5 will be affected by an upgrade is higher,
especially if there happens to be a single highly likely to break item in
the group.  Being able to detect these problems slightly easier is small
recompense for being more likely to face them.

> Another point is that it is simply not possible to restrict programmers from
> doing certain things. The best example is bonobo-conf itself. Although GConf
> does not support to store complex types I have found a workaround. So you
> will never reach you goal that everybody stores basic types. Instead we will
> have multiple workarounds, which is certainly the worst situation I can
> imagine. Complex types exists and we have to provide a solution to store
> them.

You are right in that it is not possible to restrict programmers - you
have your workaround, corba_any_to_string is suggested, as was encoding
various things as strings, and so on.  That does not mean, however, that
one should encourage doing things in a bad way just because they could
well be done that way anyway.

Providing good support for complex types is important, because people will
use them despite their failings for configuration data, but needing to
provide support is a far cry from basing the whole system around them.

> It is absolutely no problem to write a console based administration
> tool that can handle CORBA_any.

It is possible, yes, it is significantly more complicated than simple
types, but that aside, how hard do you suppose it is to provide scripting
tools to deal with CORBA_any data?

If you have 200+ machines to do some carbon copy configuration on, how
thrilled are you going to be to discover that you can use a nice GUI
plugin widget on each machine, but the console tool is still under
development, and there are no generic scripting tools available?

Your best argument to me was atomicity of structured data.  I counter that
by pointing you at a very early message that stated the desire to have
GConfChangeSet writes atomic.  This avoids the need for explicit locking
support and data model complex types while retaining network efficiency
and data integrity.

Now, I doubt this will change your mind, so I'll just remind you that I'm
not directly involved in the development of GConf, so it's not me you need
to convince; I've given you a few reasons why structured types are
probably better supported in the API than the data model, but Colm and
Havoc may have other reasons.

-- 
bje