Re: GConf vs. bonobo-config

[Sander Vesik <Sander Vesik Sun COM>]

On Fri, 15 Jun 2001, Michael Meeks wrote:

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

errrr.... 
	* platform coherency is achieved by everything simply using GConf
	* something built on top of gconf is always fatter than using jsut
	  gconf

I'd like to see the cleanliness part substaniated.

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

This is the wrong take. Unless there are good reasons to break
compatibility, it should alsways be maitained. I haven't seen good reasons
for breaking it walking around.

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

So the pointers to the proof of solving this are where?

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

Assuming that for anything a 'C' api is for some reason worser than CORBA
API does not stand up to any scrunity. Among other things, as it stands
there isn't even an easy way of getting that CORBA to really work with
anything but C.

>
> 	Regards,
> 
> 		Michael.
> 
> -- 
>  mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot
> 

	Sander

One day a tortoise will learn to fly
	-- Terry Pratchett, 'Small Gods'