Re: GConf vs. bonobo-config

[Dietmar Maurer <dietmar ximian com>]

Havoc Pennington wrote:

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

I am unsure if this is really needed, but maybe it is useful. If so we can add
another method to the CORBA interface, called addMandatoryDatabase(), or add an
additional parameter to addDatabase:

  void addDatabase (in ConfigDatabase default_db, in string path, in boolean
mandatory)


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

Well, you always have to query that additional database.

> Another big source
> of that complexity is error handling, which I also consider an
> important feature.

Sure, I know that.

BTW: storing everything inside a single directory makes thinks much simpler.

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

Yes, we are talking about implementation. No one ever mentioned that we want to
change the overall design.

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

We use moniker, so everything is already there ;-)

"config:"  return the default database.
"gconf:"  returns the GConf database.

- Dietmar