Re: GConf vs. bonobo-config

[Gediminas Paulauskas <menesis delfi lt>]

On 16 Jun 2001 11:41:44 -0400, Havoc Pennington wrote:
> 
> Miguel de Icaza <miguel ximian com> writes: 
> > 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.
> 
> <broken record>
> No, there was a discussion of why you decided to provide a Bonobo
> interface to GConf. Go read the thread. Go read the first announce for
> bonobo-conf. They are about a WRAPPER.
> </broken record>
>  
> The reason I didn't take your patch is that no reason was given a
> wrapper would not work. And you still have not given such a reason.
> 
> So don't even pretend your code forking was justified for technical
> reasons until you can come up with one.

As Miguel pointed out back in February, there is at least one reason why
the wrapper around gconf is not a solution:

you can store CORBA_Any with gconf: moniker, but that data is stored as
string made of lots of entities like &gt; so it is not usable with any
perfect-generic-editor-for-gconf-databases.

By dropping gconf it is possible to write another moniker which does not
have that problem (or maybe xmldirdb already solves that?). Or GConf
needs much fixing, but Havoc refused to add CORBA_Any or support to
gconf itself; and also drop GConfValue for compatibility reasons.

IMHO, the best solution with most features and cleanest code would be to
migrate gconf features to bonobo-conf and obsolete gconf then.

BTW, the API freeze date is near. The emphasis is on *API*. I.e. library
interfaces need to be agreed upon quickly. With bonobo-conf there is no
problem because there is no API.

After the freeze, testsuite can be added, bugs fixed, tests done,
translations made etc. So there more than a month left: these things can
be worked on until November.

And there was almost no hacking on gconf this year, sound like forever
freeze of API because "we need backwars compatibility" and "everything
else is implementation detail".

--
Gediminas Paulauskas
Kaunas, Lithuania