Re: GConf debate ... the hermenutical key.

[Sander Vesik <Sander Vesik sun com>]

On Fri, 15 Jun 2001, Michael Meeks wrote:

[snip]

> 
> 	GConf must hide its CORBA API as an 'internal implementation
> detail'. This allows the internal implementation to be changed at random
> in future to 'Hub' [ when it has got past the abstract drawing board ].
> 

Exposing anything but the bare needed parts of the API is bad practice. 

> 	Of course, bonobo-config takes the opposite view - bonobo is the
> future, CORBA is at the core of GNOME, and thus we should re-use the
> existing PropertyBag / CORBA_any / DynamicAny API [1]
> 

I don't think this is a percice description. 

> 	Thus bonobo-config ties nicely into the GNOME platform, it
> integrates with it well, it is accessed through the moniker interface, it
> uses fast in-proc CORBA accessed caches, it allows the standard property
> bag API to be used to access configuration information, it can be used by
> any scripting language with CORBA support trivialy etc. etc.
> 

Here's the catch for any other language but C : implement a corba binding
and anything is trivial. Of course, lots of other things become trivial if
we force everyone to rewrite in C++ or Java or Modula 3 or APL or Fortran
95 with OpenMP.

> 	GConf re-uses almost nothing - pointlessly re-inventing almost
> everything, it doesn't integrate with the GNOME 2.0 platform, it needs to
> be wrapped specialy per scripting language, it is not capable of storing
> structured data simply, and it is a dead end IMHO. It ties nicely into the
> 'Gtk+' platform.
> 

Sorry Michael, this paragraph is pure demagogy. 

> 
> 	As for history, and the inevitable consipiriacy theories -
> Dietmar, Miguel & my abhorence of GConf has been public knowledge for many
> months, see the gconf lists - bonobo-config was developed for both
> gnome-1.4 and 2.0 as a way of hiding GConf from the user [ behind a
> standard Bonobo PropertyBag API ]. It was developed in public CVS from the
> beggining.
> 

Fine. I haven't seen any arguments against 'bonobo-config, the
bonobo-binding for gconf' so far. Indeed, why should anybody be against it
if some people go out and make an optional component that allows those who
want to access gconf through monikers?

> 
> 	Anyhow, with all this in mind - whether bonobo-conf is installed
> or not, it needs no extra code above what is in libbonobo [ it uses
> standard interfaces ]. And it needs no separate logic, since it is
> accessed via monikers, it is clean, simpler and more elegant. It installs
> 0 client headers.
> 

You mean besides what is inside it, including for accessing non-gconf
storage?


> 	With all this in mind, I would like to propose that Miguel,
> Dietmar, Martin and myself are doing the best thing by using CORBA /
> Bonobo across the Gnome 2.0 platform in order to provide a powerful
> component technology within the 2.0 timescale. I would further suggest
> that proponents of GConf are either suprised by the joy of a consistant
> component future and are recovering slowly, or convinced by the suggestion
> that CORBA is not the future.
> 

Along the present tracks, there doesn't seem to be any future but
short-term arrival of complete entropy. The way is paved with good
intentions.

[snip]

> 	Amen,
> 
> 	Now everyone can flame me instead I suppose,
> 
> 		Michael. [ who leaves for the weekend ]
> 

[snip]

> -- 
>  mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot
> 
> 
> _______________________________________________
> gconf-list mailing list
> gconf-list gnome org
> http://mail.gnome.org/mailman/listinfo/gconf-list
> 

	Sander

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