Re: GConf design goals.

[Colm Smyth <Colm Smyth ireland sun com>]

Hi Andrae,

Thanks for your support, the bonobo-conf thread has become a little
weary but it's nice to know that other developers see some of the issues
with this proposed feature.

Colm.

>Delivered-To: gconf-list gnome org
>From: Andrae Muys <amuys shortech com au>
>X-Accept-Language: en
>MIME-Version: 1.0
>To: gconf-list gnome org
>Subject: GConf design goals.
>Content-Transfer-Encoding: 7bit
>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>
>
>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
>
>_______________________________________________
>gconf-list mailing list
>gconf-list gnome org
>http://mail.gnome.org/mailman/listinfo/gconf-list