Re: GConf and bonobo-conf

[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 ?

        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.

> - 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.

> 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:

idl:

module Foo {
        struct Baa {
                long a;
                short b;
                string c;
                sequence<long> e;
        };
};

C:

serialize_config (Foo_Baa *s, CORBA_Environment *ev)
{       
        CORBA_Any any;

        any->_type = TC_Foo_Baa;
        any->_value = s;
        
        whatever_api_set_property ("/wherever", &any, ev);
}

Foo_Baa *
hydrayte_config (CORBA_Environment *ev)
{
        CORBA_Any *any = whatever_api_get_property ("/wherever", ev);
        Foo_Baa *s = any->_value;

        any->_release = FALSE;
        CORBA_free (any);

        return s;
}               

        Ok; hackish, untested etc. etc. But lets line this up against what
I understand is the alternative:

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.

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 ?
                
        Regards,

                Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot