Re: GConf vs. bonobo-config
- From: Michael Meeks <michael ximian com>
- To: Sander Vesik <Sander Vesik Sun COM>
- Cc: Dietmar Maurer <dietmar ximian com>, Havoc Pennington <hp redhat com>, Martin Baulig <martin home-of-linux org>, gnome-2-0-list gnome org, gconf-list gnome org, gnome-components-list gnome org
- Subject: Re: GConf vs. bonobo-config
- Date: Fri, 15 Jun 2001 22:25:15 -0400 (EDT)
On Sat, 16 Jun 2001, Sander Vesik wrote:
> > > * Why do we want it anyways?
> > unified interface for property values, code cleanup, code reuse,
> > CORBA interface, scriptable, CORBA_any, ...
> These are *secondary* benefits - except for CORBA_any, none of which
> weight up porting. Also, any code that is additional to mere gconf
> wrapping counts against any code sharing aspect of it.
I disagree, platform co-herencey, cleanliness, and thinness come
well in the primary capability.
> > > General questions:
> > > * porting - how much additional porting will using bonbo-config
> > > instead of gconf introduce?
> > We can even provide fully compatible function.
> I'm afraid this is backwards. It should do that first and foremost and
> then add any and all other features on top of that. At least if it is to
> fill the rule it seems to be targeted at.
Why should it be compatible ? how much data is stored in GConf
databases ? I challenge people to show me a deployed GConf database that
is used reliably with much data in it. Regularly trashing ~/.gconf seems
the only way to overcome some of the exotic behavioral problems I have
> > > * how much overhead does it add?
> > none
> That's an impossiblity. Even a striaghtforward wrapping function call with
> no parameter changes has an overhead (unless inlined). The additional
> overhead (both average and worst case) needs to be known.
Why have GConf at all then ? it adds extra bloat, adds an extra
API that encourages bad practice 'C' API creation, and devalues the
mmeeks gnu org <><, Pseudo Engineer, itinerant idiot
] [Thread Prev