Re: GConf vs. bonobo-config

[Miguel de Icaza <miguel ximian com>]

> I'm not at all aware of the details of the configuration databases, but I
> am very interested in the reason someone had to implement a new
> configuration scheme at all. It seems like an utter waste of time and
> energy. And then suddenly without any discussion, bonobo-conf seems to be
> meant as the default for Gnome 2.

There is a pretty extensive discussion on GConf-list and the
gnome-components-list as to why we decided to implement a new
configuration mechanism.

There are many reasons, and you can find a more detailed explanation
on the various URLs that Martin posted before, so I will not repeat
what has been already said in the past.

GConf has a number of problems in my mind:

	* Another C API that needs to be wrapped.

	* No support for arbitraryly complex data, programmer needs to
          flatten out data structures.

	* Uses CORBA, shares with bonobo-conf the CORBA dependency,
          without actually commiting to a sane CORBA interface that
          can be reused.

Bonobo-Conf begun as an idea to reuse the same Bonobo interfaces we
had on the system and integrate those with the moniker system.  A lot
has been discussed about having "GUI editors" for GConf values, which
is yet another task to implement.  By using Bonobo, you can use the
same Property Editors that you can use for Property Bags to edit your
configuration databases.

Now, that being said, Dietmar and Michael did review the design many
times until we arrived at a compromise for performance, scalability
and configuration through moniker stacking.  

If people look at the code, you will see that Bonobo-Conf design is
very nice, very clean and it is overall a better configuration system
for the future.  

I encourage people to read the bonobo-conf source code to better
appreciate its beauty (both conceptually and as an implementation)

Best wishes,
miguel.