Re: syntactic sugar vs. design

[Byron Ellacott <bje apnic net>]

On 22 Feb 2001, Havoc Pennington wrote:

> Getting into specifics, I felt that Andrae Muys had an excellent point
> about the general goals of GConf, and Colm makes an excellent point
> that you want scripts and command line tools to be able to transform
> and manipulate the config data easily. These are real design
> requirements for GConf.

Exactly right.  My greatest concern is how complicated administration
tools will become if we start adding complex data types at the lowest
level, rather than higher up.  I'm also somewhat concerned about the lower
migratability of complex structures, but that's an issue application
developers can face on their own.

> This preserves the simple directory hierarchy implementation of GConf
> and the simple sysadmin/configtool view of things (a struct is just a
> directory) but gives us a way to work with directories that isn't
> painful, it's just get/set fields by name and then push the whole
> struct into the database at once.

So the API or engine is translating the tree structure to key/field =
value ?

> The primary penalty that persists is that you can't have lists of
> complex datatypes, other than giving them all a unique name
> (gconf_unique_key() kind of thing) and sticking them in a directory.
> The simplest solution to this is to allow GCONF_VALUE_LIST etc. to
> contain sub-lists. I rejected that for GConf 1.0 because it's a lot of
> implementation complexity. But it's an evolutionary extension of
> current GConf that's easy to do.

If you map a struct like thus:

struct _foo {
  char *field1;   // maps to .../foo/field1/
  int field2;     // maps to .../foo/field2/
} foo;

you can map an array like thus:

int foo[4] = {
  0,             // maps to .../foo/0/
  72,            // maps to .../foo/1/
  14,            // maps to .../foo/2/
  -1,            // maps to .../foo/3/
};

and preserve the simple data model while providing convenient high level
APIs when they are needed.  As an aside, I feel the list type should be
dropped entirely in favour of this approach, as the contents of the list
here can easily be either simple or complex types, and presenting one
solution to both problems seems neater; the list type is also the most
complicated part of the data model as thing stand.  Less easily, they
could also be mixed types, with a stronger focus on GConfSchema use, but
this isn't a matter under discussion.

> In any case, CORBA_any is a variant data type. Variant data types are
> a dime a dozen, there's also GValue even just within GNOME. I don't
> see how it's anything more than a syntax issue. So the problems being
> discussed are how the syntactic sugar of CORBA_any can lead
> application programmers to mangle the GConf design goals
> (upgradability, manageability, scripting). Valid concerns when picking
> a syntactic sugar. But I still see no reason why CORBA_any has to be
> in the GConf core, it remains syntax and syntax only.

I have an issue with using CORBA_Any for the fact that it introduces CORBA
to the syntax of an application that may not have had any other use for
CORBA; better to have ones own variant type, IMO, but as you say, this
isn't relevant to the GConf data model design.

> So what would not be syntax? Changing GConf to basically be a
> simplification of LDAP and be tightly bound to LDAP; then you would
> allow queries and such. Or changing to a much more XML-centric model,
> with DTDs describing application preferences instead of GConfSchema,
> and maybe stylesheet transformations getting involved. Those would be
> fundamental redesigns. But so far no one is suggesting moving away
> from key-value pairs in what's essentially a giant hash table. So we
> are looking at pretty much the same GConf no matter how this is
> resolved.

I am suggesting we not only keep the key-value model in a hierarchical
organisation, but that we also keep the types for value as basic as
possible, and allow complexity to be provided by application APIs; from an
administration point of view, *all* application data can then be viewed as
simply typed key-value pairs, and with proper use of GConfSchema,
understood, documented, and maintained.

-- 
bje