why share implementation? (Re: GLib debate)

[Havoc Pennington]

On Mon, Jul 21, 2003 at 04:55:15PM +0200, Alexander Kellett wrote:
> i'm confused as to why people would even bother sharing code in 
> the first place, more time is wasted on this thread than it would 
> take to just reimplement in both toolkits.
> 
> shared code will just slow everyone down, it will make for
> untested specifications and will just cause a thousand and 
> one more conversations about toolkits in the end.  
> 
> so. why even bother? most of the code will end up in the 
> wrapping of this low level stuff in higher level apis anyway
> and if it doesn't, well, its proof that its not lowest common
> denominator code.
> 

A fair question, and more interesting than the GLib argument IMO.

First I think it's clear that it's somewhat context-dependent. In some
cases sharing only a spec is right, in others sharing only code is
right, and in some sharing both is right.

We already have examples of each:

 - the menu system shares only a spec between gnome/kde, and would be
   a fairly big headache to share code. Also for many web standards 
   such as HTML we share only specs.

 - we share both specs and code for Xlib and many other X bits;
   for libpng, and other image libs.

 - we share only code for the fontconfig font configuration system,
   and perhaps in the future for the Cairo (Xr) library.

Of course gnome and kde aren't the only ones involved. For example,
Mozilla, XFCE, and GNOME all share GTK+.

The end of the spectrum where you obviously need to share only a spec
is when the spec is trivial to implement, such as DND types.  There
sharing code would just be silly.

You need to at least _have_ a spec anytime you're talking about
protocols or file formats that are exchanged between multiple
applications. This is regardless of whether the spec is shared; it's
simply good and essential software engineering to know what the format
or protocol is, in detail, because otherwise you have no chance of
keeping it backward compatible, among other things.

Such specs are also required to do version migrations. For example,
Windows seems to have had a number of different GUI APIs. GTK+ has had
3 iterations. Across these migrations, it's essential for the old and
new version to work together.

So, well-specified protocols and file formats are essential; even if
we had only one GUI toolkit and only one desktop and all the major
apps used that toolkit/desktop.  Cutting this corner is simply bad
engineering practice. Of course, all of us are probably guilty of
cutting it from time to time, but that doesn't make it OK. ;-)

Sharing only specs can be a lot of work. For a complex spec such as
the menu spec, we clearly need a conformance test suite before we can
have any faith at all that Waldo and I have implemented it the same
way.

I think sharing code becomes important when we're talking about
something that is relatively complicated, and is really about
within-application behavior rather than inter-application
communication. Also, when the functionality is pretty hard to specify
precisely due to complexity, or so tightly tied to the UI and other
sources of change requests that it's very likely to change a lot over
time.

When sharing code, it also helps if the shared code is in a fairly
well-defined/confined area such that it can be wrapped and forgotten
about. People using GTK+ or Qt don't need to touch libpng or
fontconfig directly.

Sharing code can be simply a practical step because we only have one
person to do implementation work, too.

To pick one of the more ambitious efforts proposed so far, for D-BUS
we have both a protocol spec and code. The code is designed to be
maximally general (no GLib, handles out of memory cases, plain C,
etc.), but at the same time if you wanted a specialized embedded or
pure Java or whatever implementation, you should be able to write one
using the spec.

I don't think we're likely to have time to implement a message bus or
IPC system twice over, following the same spec, so the shared
implementation is pretty practical for now. With the planned GLib/Qt
wrappers, everyone should see a nice API for their environment.

Anyway, I think the decision here is basically case-by-case and
app-by-app. I believe we should have the option to do whatever
combination of specs and code makes sense each time.

Havoc