Re: Non-C bindings in GNOME

[Michael Meeks <michael ximian com>]

Hi Havoc,

	Since you have so many points - I've added you to the list of
irresponsible people to decide on this one; I hope that's ok.

On Sat, 2002-08-17 at 22:13, Havoc Pennington wrote:
>  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.

	A fairly interesting argument.

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

	Well, conversely splitting out the C++ stuff from ORBit2 and creating a
separate interface for it will also suck (my) time :-)

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

	Then again - having the two bound together in the same package in this
instance should militate against either needing to catch up with the
other.

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

	It's _really_ hard to do automatic bindings for compiled languages,
indeed even for Mono - you have to generate headers since it's type safe
with no ultra-sloppy-late-linking stuff. [ Short of explicit 'Invoke'
operations ]. But I agree, it sucks to have to wrap and re-wrap stuff.

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

	Well; I must confess to being profoundly ambivalent on this point, I
have no idea what the best approach is.

> 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?

	I think the conditional compilation card is pretty weak; not something
we really want to add back to Gnome in a big way I think. Clearly we
have a minority of non-Gnome users who would want to disable the
bindings - but if we add it I'd want to make sure that the bindings were
built and shipped always.

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

	Agreed; and ultimately Gergo maintains the C++ stuff, and will have to
in future.

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

	Thanks for your comments; updated the gep.

	Regards,

		Michael.

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