Re: GConf vs. bonobo-config

[Michael Meeks <michael ximian com>]

Hi Sander,

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

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

	Regards,

		Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot