Re: GNOME ABI review

[Havoc Pennington <hp redhat com>]

Hi,

I should elaborate a bit on why I think it's important to have
flexibility in the future, and get ABIs right for cross-toolkit usage.
This is not primarily about GNOME/KDE.

Here are some of the gains we could try for.

1. GTK+ 3.0, Swing (and thus Java), WINE (and thus Mono among other
   things).

   Flexibility to move forward and interoperate, and have 
   a much larger set of apps that are GNOME-integrated.

   The first wave of apps ported from Windows will be using WINE or
   Swing or whatever.

   GTK+ 3.0 needs to preserve the runtime protocols found in GTK+ 2.x.

2. Same platform on handheld and desktop. 

   GPE is going to need a custom panel, window manager, etc.; but 
   wouldn't it be neat if apps required minimal or no adaptation 
   to move from handheld to technical workstation? Or at least 
   if you use the same APIs to develop an app for each?
 
   That level of de-bloat is within reach.

3. Evolving the desktop components.

   Sawfish->Metacity probably would not have been possible without the
   documented EWMH specification. Not everyone liked this specific
   change, but still it was good to have the choice and the ability to
   change.

   Keep interfaces well-defined and you can swap out implementations.

4. Speed and small size.

   You don't _want_ a sprawling/rapidly-expanding ABI. By trimming
   down the core, we give ourselves room to innovate without getting 
   too big.

   Every GNOME app is currently paying for libgnomecanvas, though 
   basically none of them use it.

5. Documentation.

   Encapsulation, documented protocols and conventions, good
   interfaces are good engineering practice.  Requiring the use of a
   specific implementation is sloppy.

Havoc