Re: GConf debate ... the hermenutical key.

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]