Re: GConf vs. bonobo-config

[Havoc Pennington <hp redhat com>]

Dietmar Maurer <dietmar ximian com> writes: 
> See bonobo-conf/idl/Bonobo_Config.idl:
> 
>   void addDatabase (in ConfigDatabase default_db, in string path)
> 
> This is sufficient for many usage scenarios. And a backend is free to
> implement a more complex schema (like GConf).

So to get the behavior where you merge workgroup settings, companywide
settings, mandatory settings, etc. you have to do that work in the
backend, or do application-specific addDatabase calls.
 
The reason I bring this up is that I think it's an important feature
and also a big source of the GConf code complexity. Another big source
of that complexity is error handling, which I also consider an
important feature.

> Bonobo config makes it possible to write fully functional backends with
> less code, because it uses existing code from bonobo. This code reuse leads
> to less complex code, which is easier to maintain and to test. That is the
> reason why I want a native "gconf:" moniker, and not a wrapper. Anyway, if
> this is not possible for various reasons, we can still use the wrapper.
> 

Sure, if we use bonobo-config in lots of places and people like it,
then it's easy to eventually make the "gconf:/foo/bar" moniker resolve
to something which isn't a wrapper but is compatible with GConf. We
can do that, no problem. But it's just an implementation detail.

I wouldn't mind seeing an extra level of abstraction just in the
moniker name, something like:

 defaultconfig:/foo/bar/

which goes to the default system config stack, which at this time is
the GConf default database. While gconf:/foo/bar hardcodes going to
GConf.

Havoc