Re: GConf and bonobo-conf

[Colm Smyth <Colm Smyth ireland sun com>]

Hi Michael,

>From: Michael Meeks <michael ximian com>
>
>Hi Colm,
>        
>        Since I found your comments most telling on the gconf /
>bonobo-conf debate :-) I thought I'd try and address a point you 
raise:
>
>On Tue, 20 Feb 2001, Colm Smyth wrote:
>> Since GNOME development is fast and we want to keep adding new
>> features, we don't want to be stuck with version-compatibility 
issues,
>> or worse we don't want to write specific code to migrate users from
>> one application version to the next!
>
>        If I understand your argument, when rehearsed it looks like 
this:
>        
>        * GConf has no structured storage so people have to 
synthesise it
>with complex path structures
>        * These complex path structures allow new fields to be added 
into
>the virtual structures at a later date
>        * Therefore GConf has an edge on the CORBA any.
>        
>        Is that essentialy it ?

This is not purely a technology question, it's also a question of
priorities.

My perspective is that the main goals for a configuration
system are that it is:

- a central interface (API and UI) for configuration access
- a repository for stable long-lived configuration data
- a way to share configuration with other applications

If GConf supported CORBA_Any at the interface level, it would be
widely used because it would be simpler and easier than other
solutions; absolutely no doubt there. 

The problem is that the GConf API was not designed to handle
self-describing data; although you can use GConf to write
a CORBA_Any (as XML, which is great), the interface is pretty
crude since you write it as a string. This is basically
turning GConf into a logically infinitely large indexed file and
giving you an API consisting of read() and write().

For the application that creates the configuration data, this is
heaven; you can write your data-structures and read them back
easily. For any other application, or a different version of the same
application that has a different version of the data-structure,
this is bad news.

Some API's, such as DOM, are designed to handle self-describing
data. However, while you can use GConf to store arbitrarily
rich data, the interface is essentially no better than
the read()/write() system calls (unless you are using one of the
native GConf data-types).

An analogy: database systems have for years stored data similar to
GConf (ints, strings, doubles, ...), but as they became more widely
used, people wanted to store documents, images, or to put it another
way, rich data.  The answer was BLOBs (binary large objects).  The
DBMS can't understand the data (yes there are hacks like datablades,
but that's beside the point), but it can store it.

This is fine, but it means that I can't use any of the power of SQL to
query that data or perform fine-grained updates.  Other applications
can't easily view or update the elements of my rich data.  This is a
great analogy for the CORBA_Any proposal for GConf; it works, but you
throw away most of the benefits of the system.  If you write a rich
data-structure as a string to GConf, here are the disadvantages:

- other apps have to "know" that this string is an XML document
  corresponding to a specific data-structure and either manually
  parse the DOM and perform an update (but how? attributes or
  tags?) or know that this XML document represents a specific
  data structure that could be converted back to a CORBA_Any

- if the data-structure evolves, then the ability to transform
  the XML from a previous version of the data-structure is lost


>        I think that while this is currently true, we are putting a
>sufficiently large burden on people with the inability to save 
structured
>data sensibly, that any marginal benefit from this sort of transition 
is
>not significant.
>
>        Furthermore, I believe the issue could be trivialy fixed ( 
for a
>future version of gconf in this way ):
>
>        Any *any = whatever_api_get_any (
>                pb, "/key/for/value", TC_of_the_type_I_want, ev);
>                
>        Since we can walk both the requested and the serialized 
typecode
>structures, we can provide _any_ level of forward / backwards
>compatibility required, any mappings neccessary between the two _And_
>provide the nice feature that the data is layed out in simple C 
structures
>at the other end, in a format the app can trivialy use as its 
internal
>representation.

This seems to be saying "I'll gladly pay you Tuesday for a hamburger
today" ;) or to put it another way, "I'll choose a quick solution
today because I know that I can write a hard solution tomorrow".
I don't think that it's so easy to write code to parse the 
data-structure and migrate the data members to an updated
data-structure, in fact I'm sure it's harder than writing
the "serialization" (configuration-saving) code using GConf
primitive data in the first place.

>> - easy to edit; users will be able to use the GConf tools to change
>> values; gconftool can display and edit values, and the upcoming
>> Gtk+-based gconfedit application will also be able to browse, 
display
>> and edit GConf.
>
>        I just played with a recent version of Dietmar's nice 
bonobo-conf
>stuff, it's well worth looking at - you will need HEAD bonobo and 
ORBit (
>bug fixes ), but it provides an extremely powerful view of what can 
be
>done with both bonobo, monikers and gconf.

I am sure it's incredibly cool, but it's some cool technology
on top of a system (GConf) that was designed with different goals in
mind (easy to learn, easy to develop, easy to use); it was
not designed to handle rich data.

>> Writing binary data (even with type information) into GConf 
eliminates
>> many of the advantages of GConf. It doesn't even reduce the amount 
of
>> code you need to write;
>
>        Lets try a little code fragment:

You didn't include the code that would be needed if you decided
to add a new data-member to your structure; that is the part
that's problematic when GConf can't interpret the opaque (but
rich to the originating application) data that's being stored
in it.


>C:
>
>serialize_config (Foo_Baa *s)
>{
>        int i;
>
>        gconf_set_long ("/wherever/a", s->a);
>        gconf_set_short ("/wherever/b", s->b);
>        gconf_set_string ("/wherever/c", s->c);
>        gconf_whatever_it_is_to_do_longs ("/wherever/e", s->e);
>}
>
>And similarly to de-serialize.

If GConf was *slightly* different, it would be easier; the
problem is that GConfValue expects to own the actual data.

If GConfValue could also "borrow" a pointer provided by the
application, then with the aid of a (possible) new
GConf data-structure then you could do something like:

	GConfGroup *group = gconf_group_create(engine);
        gconf_group_bind_long (group, "/wherever/a", &s->a);
        gconf_group_bind_short (group, "/wherever/b", &s->b);
        gconf_group_bind_string (group, "/wherever/c", &s->c);
        gconf_group_bind_long (group, "/wherever/e", &s->e);
        
Then writing and reading would be easier:

	gconf_group_get(group);
	
and

	gconf_group_set(group);

The nice part about this approach is that it can use the existing
infrastructure, but it provides an easier API for structured
reads and writes. It allows fine-grained access to the individual
data-elements, allows schemas to be assigned to the individual
keys, allows data members to be added without stopping old
configuration data from being read - just because it works with
the basic GConf storage model.

>
>And naturaly, as the structures get more complicated, the sheer bulk 
of
>code, number of string constants, link penalty, runtime cost 
increases in
>magnitude worryingly.
>        
>> I would like to propose a mechanism that allows a DOM-based 
interface
>> to GConf; I believe this is equally powerful but more flexible.
>
>        Sounds most interesting - I wish I had read and absorbed the 
DOM
>API, where can I find a copy of it ?

DOM is a very low-level API for XML documents, which you can find
documented in many places but you could start with www.w3c.org.
I expect that a web search-engine and the incantation "dom tutorial"
would also be a good path to enlightenment!

Colm.

         
>        Regards,
>
>                Michael.
>
>-- 
> mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot
>