GConf debate ... the hermenutical key.

[Michael Meeks <michael ximian com>]

Hi Guys,

	Ok, so ... there is ( to my mind ) a big secret behind all this
debate, and once understood it explains:

	a) Why the GConf design is 100% unacceptable to the Bonobo / Gnome
	   2.0 team.
	b) Why the Bonobo-conf design is disliked by the Gtk+ team.

	So, here goes: at GUADEC I spent some time remonstrating with
Havoc in private over a whiteboard explaining the benefits of storing
CORBA Any's - their mapping to the structured storage, their flexibility,
upgradability etc.

* 	After some considerable time I got the frank response "We don't
* think CORBA is the future".

	This for me is the key to understanding what I will call the
'RedHat' position:

	* Gtk+ is the platform.
	* We need a new component system [ hub ].
	* That component system is not ORBit / Bonobo.

	My position is more like:

	* GNOME is the platform.
	* Problems exist, they are not insurmountable.
	* Lets iterate towards a better solution and build component
	  software.

	The consequences of this difference of opinion are many, in this
case:

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

	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]

	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.

	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.


	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.


	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.

	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.


	I see a 2 prongued attack on this so far very successful plan
for GNOME 2.0 from various people:

	* bonobo-config FUD: it's slow, it doesn't work etc. :-)
	* it'll never be done in time FUD

	In short, it's not slow, it does work and it is to a large extent
already done, and it will be done on time.

	So, there goes - I wholeheartedly support Dietmar and Martin, and
totaly refute[2] the notion that CORBA / Bonobo is not the future - lets
make it that.

On 16 Jun 2001, Martin Baulig wrote sage words:
> With GNOME 2, there are no "non-component based apps", Bonobo is
> integral part of the platform, so you always have bonobo-config in
> your app.

	Amen,

	Now everyone can flame me instead I suppose,

		Michael. [ who leaves for the weekend ]

[1] - instead of inventing yet another [ dire and limited ] C value union
and a load of new, tiresome manipulators - eg. at least consider using
GValue for goodness sake.

[2] - I know 'I refute' is not a refutation in and of itself, but since
this is the politicaly fashionable word to misuse in the UK currently, and
this argument seems to be political knniving instead of technical debate I
thought I'd use it.

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