GConf design goals.

[Andrae Muys <amuys shortech com au>]

I have been rather disturbed by the push to have GConf support rich data
blobs.  Specifically, when I read Michael Meeks statement

"        Then please read ORBit/src/orb/dynany.h, however to an extent
you
are right, if you have a tight contract between two apps they talk
through
an interface, and this should be specified in IDL somewhere."

I fear that the conceptual elegance of GConf may be discarded in the
name of expediency.

I was attracted to GConf after reading hp's white paper featured on
developer.gnome.  So I thought I might quote some of it here, as I feel
the discussion is ignoring the design goals of GConf.

First GConf is intended to fulfill the same basic role of the windows
registry, but (with the advantages of hindsight) dodging its problems. 
The specific problems identified in the white paper are:

====
  -  It's very difficult to manage a large number of computers; system
administrators can't install defaults, or push changes out to multiple
user computers. Proprietary add-on tools exist that try to resolve this
problem in various (rather frightening) ways.

  -  The registry contains lots of undocumented, cryptically-formatted
data, and regedit is therefore dangerous and difficult to use.

  -  The registry becomes corrupted, and this tends to destroy the whole
operating system installation.
====

This is summarised immedately after as

[GConf] provides a simple configuration data storage interface to
applications ...
[and] make[s] things easy for system administrators.

So far the debate over embedded rich data types has almost exclusively
focused on the former.  However I would suggest that the latter vital,
possibly even critical to GConf's success.  Personally I consider
administrability to be both the single most important requirement and
contribution of GConf to GNOME.
Along these lines the paper touts five of GConf's features.  Two of
these are focused solely on making the sysadmin's job easier.  Only one
is there to support developers.

So why is this important?  Because rich data types, while incredibly
convenient to app developers (I recognise this, after all I am an app
developer), are fatal to administrability.  Imagine you have connected
to a box from a VT100 terminal, you have a bash prompt, and you need to
fix a department's desktop settings.  How do you do it?

Yes by all means provide powerful Bonobo config dialog components for
your application.  But *don't* prevent my sysadmin from fixing things by
hand if they get broken, and rich data will tend to do this.  Michael
talks about having "a tight contract between two apps", I ask him to
explain how Nautilus and gconfsole are tightly coupled?  The key here is
to permit the development of general purpose applications to administer
the configuration database.

Now regarding the various efficiency/api issues raised during this
debate.  I can't see how the network latency claim necessitates a move
to rich structs.  I would rather see the daemon/client made smarter then
the API complicated.    The traditional solution to high latencies is
not more complex reading patterns, but simply to do read-ahead with
client side caching.  I see no reason why this can't be done here. 
GConf.idl already permits various batch lookups, and the client can
always register a root listener to receive batch notification of cache
invalidations.  (Just noting that by client here, I mean the
GConfEngine, not the application).

As far as the API is concerned, as a developer I want it as easy as
possible.  However I don't copping out and abandoning the "Plain Text"
approach is the right way to do it.  I feel that alot of this can be
achieved relatively painlessly by taking better advantage of the GConf
schema's.  [In fact I would consider a GConf schema editor to be a
priority to encourage app developers (as lazy as I know I am :) to
document their GConf data.]

Specifically I feel it is necessary to be able to declare in the
GConfSchema that subdirectories will match a specific sub-schema and
possibly provide [administrator editable] caching hints for branches. 
This would then allow the client library to provide utility functions
that permit the developer to register a field-name->struct format entry
that could be validated against the stored schema and permit single
function get's and set's of the data.

consider this:

typedef struct Colour_ {
  int r, g, b;
} Colour;

int main() {
...
    GConfStruct *mystruct = gconf_new_struct("r",
G_STRUCT_OFFSET(Colour,
r),                                               "g",
G_STRUCT_OFFSET(Colour, g),
                                             "b",
G_STRUCT_OFFSET(Colour, b));
...
    Colour *colour = gconf_get_struct(mystruct, "/apps/myapp/colour");
}

Now we have the appearance of rich data in the API, but the actual data
is stored as fundamentals that can be viewed, edited, transformed, and
otherwise manipulated without the need for fancy tools, or worse, custom
GUI components.

Now the above can be done without modification to the current Schema
format, but my suggestion to modify the Schema would permit the above to
be done with runtime typesafety.

Note that the signature of gconf_get_struct there is probably
inadequate.  I feel a better option would be something along the lines
of

error = gconf_get_struct(struct, metastruct, dirname, unmatchedkeys);

but even this may not be adequate (I can see the possible need for some
sort of isDefaults struct or something).

Anyway, this email is long enough.

Andrae Muys