The nature of the Bonobo freeze.

[Miguel de Icaza <miguel helixcode com>]

I want to explain a bit more about the Bonobo API/IDL freeze.

I am as sad as everyone else to see the Bonobo 1.0 release slip
because one reason or another.  I want to have a robust, reliable
system as much as everyone else.  As I said before, I wanted Bonobo
1.0 a year ago, not today, not in a month.

Deadlines slip, software gets delayed, software breaks.  We have to
deal with this in the most graceful fashion.

* Explanation: Why did we break Bonobo UI handler?

	Because when I assigned Michael the task of fixing the
	problems in Bonobo for the UI handler, he told me about all
	the brokeness in it, and explained to me over and over that we
	would have to rewrite it.

	I told Michael `Michael, lets not do this now, UI handler is
	complex, and I dont think you can fix it on time for the
	freeze that Eazel demands'.  This was in August, at the LWE.

	* What is the UI handler?

		The UI handler is a set of CORBA interfaces and API
		functions in Bonobo that handle menu merging and
		toolbar merging and management across Bonobo
		components.

		The UI handler is responsible for this auxiliary
		process in providing an integrated environment for
		applications. 

	* What was the problem with the old UI handler?

		Michael kept telling me that architecturally the old
		UI handler was broken and that it needed to be fixed.
		A description of some of the problems is available
		here:

		http://cvs.gnome.org/lxr/source/bonobo/doc/ui-handler.txt

		Michael had become aware of the problems in the old UI
		handler code mostly because external reviewers that
		were using it were pointing out all the broken things
		in it (Torsten working on the OpenOffice/Bonobo
		integration was one of them).

		I read that thread with interest, and I was embarassed
		by the ammount of problems in it.  If I wanted to push
		for a unified component technology for Unix, this
		needed to be addressed, but we had no time.

	* What did Torsten/Michael debate?

		They debated a number of interesting approaches to fix
		the UI handler.  Jody Goldberg from the Gnumeric team
		also had a lot of input in the process, and also told
		Michael what the problems were with the current
		approach and the kind of features that we might want
		in it. 

	After LWE I took a two week vacation in Mexico, without my
	computer to try to relax and get away from work for some
	time. 

	When I came back, I found that Michael had reimplemented the
	UI handler, fixed the known problems, came up with a better
	design that satisfied the needs of everyone, except the ones
	of the Eazel team.

	He was working on a compatibility layer at that point, but the
	compatibility layer was very hard to write.  Every application
	maintainer but Eazel was willing to switch to the new UI
	handler.  So I told Michael that it was a waste of time to
	work on the compatibility layer, that the best thing was to
	deprecate it as soon as possible. 

	Michael got Nautilus to work with the compat layer on a
	branch.   The compat layer would obviously had the problems of
	the old compat layer plus any bugs in the new layer. 

	If they wanted to keep the compat layer, they could have
	maintained it, but they demanded that Helix Code/Michael
	should develop and maintain this layer.  Which I felt was out
	of the question: Helix has its own set of tasks that need to
	be done, this is Open Souce: if you break it, you get to keep
	both pieces.

	* What were the needs of the Eazel team?

		The needs of the Eazel/Nautilus team was to have
		everything frozen, even if Bonobo was badly broken.

		Parts of the negotiation were to get the people at
		Eazel to sign on fixing the basic pieces of Bonobo
		instead of forking Bonobo.

* When did Eazel demand the freeze?

	Eazel has demanded a freeze for Bonobo since around early this
	summer.  Both their schedule for Nautilus has been delayed,
	both because of Bonobo and because of other components in the
	system. 
	
* Do I like breaking interfaces?

	No, I do not like breaking interfaces.  Indeed, those who know
	me know that I am the most resistant to break published
	interfaces.

	Every time we break a published interface, every time we
	decide to do some "cleanup" and every time we decide that
	"users will be able to port to the new API" we are hurting our
	users, and we are hurting the developers that are trying to
	develop against our API.

	Indeed, I do not like the fact that the GNOME 2.0 platform
	will break so much existing code, I even tried to have a
	source-compatible GNOME 2.0 platform, but the large amount of
	changes that did not pay attention to backwards compatibility and
	the move towards `we can break everything' left us with no
	chance to attempt it.

	Given the above described problem, Havoc pushed for minimizing
	the number of "development" platforms, which is what has lead
	to the current binary compatible GNOME 1.x platform that is
	still being developed (by providing extensions in the form of
	libraries) and the upcoming GNOME 2.x platform.

	Having two platforms beats having 100 platofmrs.

	Every time our platform changes, we have to begin from scrach

* Has Eazel frozen Nautilus, or are they just fixing problems related
  to Bonobo?

	No, Eazel has not feature frozen Nautilus yet as of today
	(October 21), so their schedule has slipped as well.  Maybe
	Bonobo is in large part responsible for the slip, but the new
	features are definetly not Bonobo's fault.

	Darin at Eazel actually realized that a hard freeze on the UI
	handler would be a bad thing both for Bonobo and for Eazel, so
	Darin, Michael and I agreed on having a soft freeze on those C
	interfaces until we were ready.

* Could you have minimized the impact of the changes, what about the
  freeze in efect on the monday 9?

	Michael was working more than 16 hours a day to accomodate the
	various changes required and helping Eazel with the Nautilus
	port as well as fixing bugs in Nautilus related to Bonobo.

	This did not allow us to get Dietmar's changes on time, nor
	did it allow us to do the studlyCaps changes that we had said
	we would do.

* What about shipping GNOME 1.4 with Bonobo 0.8, and later Bonobo 1.0?

	The point has been brought up by various Eazel people: to ship
	with a set of Persist interfaces and Stream/Storage interfaces
	now, and later ship with either an incompatible set of
	interfaces, or renamed ones.

	I believe this to be blatantly lame.  

		* If we ship incompatible interfaces: we effectively
                  have created a new "sub-platform".  Applications
                  will either work with the old or the new version of
                  it.

		* Applications will have to implement two interfaces
                  the `old' and the `new'.  Which is not only
                  embarassing, but straight depressing.

		  If someone is trying to convince a group of people
		  that GNOME has the right architecture, I wonder what
		  the reply to `So, why do you guys have four versions
		  of the Stream interface?' will be.

		  Part of the changes for Gtk+ 2.0/GNOME 2.0 were done
		  precisely to simplify this nonsense for images. 

	Specially given that the "breakage" that is being suggested by
	Dietmar is limited to removing a few lines of code from a
	Nautilus helper.

* What remaining changes are there before Bonobo 1.0?

	* Use of studly caps for method naming and the renaming of
	  methods to use verb[Adjective]Noun. 

		API breakage: CORBA IDL and the C API.
		Fixable by scripts. 

	* XSync fix: There are a couple of race condition with X
          events that can kill applications that use Bonobo
          Controls/Bonobo Embeddables, and we need an extension to
          make sure that we can sync the Async X queue and the sync
          CORBA queue.

		API breakage: none.

	  This should be considered a bug fix.

	* Support for Radio Toolbar buttons

		API breakage: none.

	  This shoudl be considered a bug fix.

	* Anti aliases toolbar buttons (from Cody)

		API breakage: none.

	  Could be considered a bug fix, of feature that has no effect
	  on the API level, and can be easily backed out if required

	* Stream/Storage fixes from Dietmar.

		API breakage: small, but Nautilus would require a tiny
		patch that only removes a few lines (no new lines).

	* Generic C Listener interface

		No API breakage, as no application uses it.

	* Property Bag API improvement.

		No API breakage, only new entry points. 

Love, Love, Love,
Miguel.