Re: Non-C bindings in GNOME

[Havoc Pennington <hp redhat com>]

Seth Nickell <snickell stanford edu> writes: 
> On Thu, 2002-08-15 at 20:49, Jeff Waugh wrote:
> > I would support an expanded "integrate language bindings into the library
> > module" across all of our libraries. Obviously that's a pretty huge
> > seachange, and there are various things to iron out. If it works out well
> > with ORBit2 and maintainers support it, it could be very cool for other
> > languages.
> 
> I think this would be fantastic. We have a chicken-and-egg problem right
> now where application developers avoid non-C bindings (in my case, I
> would rather use C++ or Java) because distros often do not include some
> set of these bindings.

Here are my objections.

 1) If core GNOME is written in lots of different languages, it will
    be huge, and not interoperate with itself. Each binding stack is
    several megs of additional on-disk library, because we are doing
    manual (partially-automatic) static bindings instead of dynamic
    bindings a la .NET. The situation with garbage collection,
    threads, derivation, etc. with multiple languages in one process
    is highly, highly undefined; it's somewhat broken even within some
    single language bindings at the moment, from what I've heard.

 2) Thus we can have C plus ONE language binding used to implement 
    any non-leaf node in the dependency stack.

 3) Which language binding will that be? ;-) I would personally vote
    for Python due to strong qualitative difference from C,
    unfortunate licensing of Java, and other reasons, but who wants to
    have this argument...

 4) For leaf nodes (applications), using binding-of-anyone's-choice is
    more feasible but if we use 4 add-on different bindings, it is
    still going to add 12,15 megs of bloat to a running desktop.

 5) I do not believe that we will really save time on bindings in the
    short term, because they also have a cost in extra kinds of issues
    to debug and other overhead.

 6) The bindings have separate maintainers and are nicely modularized
    right now. We exploded libraries into lots of small packages for
    GNOME 2 and that was the Right Thing. If you pack stuff into
    single packages, the maintainers of sub-pieces disappear. This
    phenomenon has been seen hundreds of times - I can't tell you
    _why_ it happens, but I can tell you it definitely _does_
    happen. It's better to keep things orthogonal and give people
    their own little domain.

    In other words if it's right to split libgnome and libgnomeui,
    it's equally right to split out the language binding packages.

 7) "forcing" bindings on people in this way will be a big
    controversial distraction and suck up developer time, 
    and 2.2 is about USER FEATURES, please.

 8) we don't want bindings to delay any release, or complicate ABI/API
    issues, and if they are packed into the core packages we might
    e.g. have to delay 2.4 for a binding to catch up to GTK 2.4.  That
    would be unfortunate. I'd like to see minimum modules on the
    critical path to release the core user environment.

So that is short term why we should keep them separate.

Long-term, the reason is that semi-automatic partially-manual static
language binding stubs are wrong. We need to be on the Mono/XPCOM/UNO
model of doing this. And while I agree this is somewhat
star-trek-future, I think it's likely enough within a few years, and
enough better than our current approach, that we should keep the
current LB approach somewhat orthogonal/separate from the core of
GNOME. Fully dynamic, automatic bindings address all the issues of
using multiple bindings, and of bloat, that I am bitching about in the
short term for the kind of bindings we have now.


I also have in the back of my head that if we move the remaining API
to GTK such that libbonoboui and libgnomeui aren't doing much, we
could potentially mop up a good additional hunk of bloat, and with 2.4
again drop in size/speed vs. 2.0 - after already shrinking from
1.4->2.0 - and I do think this is a nice trend. The Linux desktop
including Mozilla, OpenOffice, GNOME, etc. is too slow and large for
users at the moment, and while Moore's law will help us a bit, it'd be
nice to be moving the software too. And the only way to make big wins
is to be dropping duplicate functionality. Of course that helps with
overall engineering and maintenance as well.


Now, all this considered, I think the CORBA/C++ bindings may be a
special case, because of tight binding to orbit-idl and just the fact
that the maintainers are wanting to do it that way. Or maybe more
importantly since there is a CORBA spec for C++ and C++ is sort of the
"standard" way to use CORBA. So this functionality naturally belongs
in the ORB.

Also I don't think there's much harm in including language bindings in
a module if the module maintainer is maintaining those bindings him or
herself, especially if there's a --disable-language-foo option to
configure, and core gnome modules aren't depending on the binding.  I
guess libxml2 and vte both contain bindings already, right?

Some bindings creeping in this way doesn't bug me much. But I would
not want to see lots of random language bindings in core GNOME, and I
wouldn't want to see us systematically including multiple language
bindings in every library module. Splitting modules according to
maintainer duties is often a good idea.


BTW I don't fully agree with your analysis on why people don't use
bindings. I think it's because most gnome programmers are C
programmers, the docs are all for C, and people just don't bother to
learn the bindings. Also the bindings often lag the C APIs in annoying
ways or tend to change more often, historically. But the most
successful bindings have been the really complete and
actively-maintained onese such as pygtk and gtkmm. Red Hat uses pygtk
extensively as you know.

Note also that people using Python tend to use the "blessed" python
toolkit (Tk), and those using Java tend to use Swing, and so on.  One
thing I might do to promote bindings is to e.g. convince the Python
people to get over the rather archaic Tk thing.


But again, ORBit/C++ may well be an exception. I'm not familiar with
the details of this situation at all.

Havoc