Re: GConf debate ... the hermenutical key.

[Dietmar Maurer <dietmar ximian com>]

Sander Vesik wrote:
> I can see why a GNOME and only-GNOME application
> might be better off using
> *A* CORBA based API for configuration access. For others, gconf sounds
> a
> lot better solution ('cause you just need to pull in less non-native
> code).
Isn't libgnome the core part of GNOME. I thought we are talking about how
to access configuration values inside libgnome, and all other libs above???
If you see the advantage then we have no problem - then we can use my approach
inside libgnome, because libgnome it is the core part of each GNOME application.
> You have basicly offered no proofs for almost any
> of your claims, among
> other things that it completely wraps the gconf api on the functionality
> side, that it provides similar or superior error reporting and recovery.
> It does not appear to have any test code (or for that matter, a place
> to
> report bugs).
It seems that you ignore most mails, and missed some major points.
> Whetever I agree or not is largely immaterial - convince
> the app
> developers - hells, for that matter, take the damn trivial time and
> post
> an overview of where what and why (preferably taking the time to prove
> any
> claims) to gnome-hackers and gnome-devel-list!!! For all anybody cares,
> discussing configuration systems in gnome-components is the same as
> doing
> so in giant-space-hamsters.
I have tried to explain what we want several times, but people like you
are simply ignoring that mails, don't know why. Maybe I must post them
several times? So here is the mail I posted in the morning:
 
> I also thought we agreed on using the "GConf:" wrapper, and to use the
> PropertyBag API to access the values. Unfortunately people still mix
> different thing, and use the term bonobo-conf[ig] somehow improperly, but
> that is maybe my fault. IMO there are two totally different things to
> discuss. The more important one is:
>
> 1.) Which client side API should we use, either:
>
>         - GConf client API or
>
>         - The bonobo API (PropertyBag/EventSource/Monikers)
>
> Please consider the following before you write an answer to this mail:
>
>     - Please notice the term "client side"
>
>     - We still use the GConf backend, so you can do exactly the same
> things as before
>
>     - It has absolutely zero influence to any existing application
>
>     - We want to use the bonobo API - we do not invent anything new.
>
>     - The only code required from the bonobo-config package is the
> "gconf:" moniker. That moniker is only a few line of code, since its a
> wrapper. And it is dynamically linked (moniker).
>
> So the question is relatively simple, and this question needs to be
> decided now. Maybe we can find an answer to it without first founding an
> architecture committee?
>
> So this was the question which needs to be decided now.
>
> Anything following is unrelated to the Gnome 2 release. The second
> question is:
>
> 2.) What is the best way to implement a system like GConf?
>
> I prefer reusing existing code like bonobo, and I showed a way how we can
> implement it (bonobo-conf). I simple don't like to work on totally
> outdated code as found in GConf, and I think it needs a major cleanup.
>
> Anyway, lets first talk about the significant things raised in 1.)