Re: GConf vs. bonobo-config

[Miguel de Icaza <miguel ximian com>]

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

We implemented a PropertyBag interface for GConf that you did not
accept.  

We debated on a list, where nothing was agreed on, and where Colm
basically got tired of debating the same topic over and over.  So
Dietmar did what any hacker would do: work on useful code rather than
argue. 

Then we implemented PropertyBag by wrapping GConf.

Then we found that a number of interesting options was available to us
if we dropped "PropertyBag" as the backend storage and defined it in
terms of a more general "ConfigDatabase" storage.

So we implemented the three of them, well Dietmar did.  I had very
little to do.

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

We did implement the wrapper, and the code might be on CVS.  I do not
know, as I do not follow the project that closely.

> So don't even pretend your code forking was justified for technical
> reasons until you can come up with one.

What forking?  We have not forked GConf.  I would not have wanted to
reuse GConf because of its architectural issues.  

> It does not need to be wrapped by language bindings, because language
> bindings can wrap your bonobo-config wrapper. i.e. bonobo-config as a
> wrapper solves this problem.

Two systems to use instead of one is my feeling.

> Moreover, the reason I gave at the time you last brought it up:
> GConf the C API is something we've already committed to supporting. So
> there is nothing to be gained by breaking it.

Because there was nothing better at the time.  And "we've already
committed to support" means some people starting using it.

Not everyone agreed, and that is why GtkHTML and Evolution did drop
GConf support (partially to its unstability and problems).

> I'm still waiting to be shown the "database stack" code so I can
> evaluate that.

Dietmar, can you point Havoc to this?

> But anyway, I still haven't heard a reason that justifies
> bonobo-config the REIMPLEMENTATION vs. bonobo-config the WRAPPER. You
> guys seem to really, really miss this point.

The implementation of GConf is poor.  The wrapper is a workaround for
a broken architecture.  I would love to see GConf fully and totally
gone, but I am not the one doing the coding.

I am just trying to explain the rationale behind bonobo-conf. 

Miguel.