splitting off bindings [was: Re: patch to TODO]

[Robert McQueen]

Havoc Pennington wrote:
>>+ - Split out bindings and import other bindings to freedesktop CVS 
> 
> Have people agreed on this approach? I don't have a sense of the
> consensus or lack thereof.

We (me, J5, davidw, danpb, robtaylor, mjj29...?) had a pretty good chat
about it on IRC a week or two ago, and the general consensus between the
people there was that it was a good plan. Some of the bindings in-tree
are seriously short on loving, and it's a real disservice to the
community to just ignore them and crank the handle of versions to 0.90
and 1.0 whilst we're really not able to make any guarantee about the API
suitability, completeness or usability of the bindings we don't have
maintainers for.

I'd consider glib and python as covered between me, robtaylor and J5,
Qt4 has just picked up, and Matthew Johnson has written a set of Java
bindings which he'd like to see in our CVS, which sparked this debate.
Mono seems totally dead to the world (although recently Adam Lofts on
IRC has been talking about a new set of bindings which he's working on),
and I'm uncertain about how mainained or relevant Qt3 is any more.

Besides avoiding versioning things we're not maintaining, some bindings
might get more attention if they were not in our tree at all, but in
their "native home". For example, perl bindings have never been in-tree,
because the perl stuff lives in CPAN, and is maintained there, or if we
see D-Bus bindings being added into Qt4 then the code would live with
Trolltech and not in our repository. This is cool and we should
encourage this where appropriate.

The only downside to splitting out that we came across is that we lose
some of the cross-binding testing that currently takes place in the main
tree -- particularly python tests itself against glib's test service as
well as the echo service and a python service, and this was held to be a
generally good idea.

The solution we came up with was to formalise this cross-testing
procedure in a seperate dbus-test module. We would define a test
interface which a binding must implement to provide a test service, and
we would define a series of method calls on this interface which a
binding must implement to provide a test client. This interface & series
would check the binding was able to do all of the basic types (you might
laugh, but in Python 4-5 months ago, nearly a third of them were somehow
missing or broken!), corner cases which will always trip people up like
empty arrays, and a good selection of real tough examples of recursive
stuff like collections/maps/structures (a{sa{s(ybiao)}} etc). The tree
could detect which bindings you had installed and make a good few tries
of some test clients against test services implemented in different
bindings. danpb seemed keen to doing some work towards this and having
these tests automated somewhat.

Obviously that might be a way off, but as an opening gambit we could at
least put the stuff in test/<binding>/ into our dbus-test tree, and run
it if dbus-<binding> was installed.

> Havoc

Regards,
Rob

P.S. As an aside, if we were wanting to consider something a little
better than CVS, now would be a good time to do it while we make these
new modules. I've been using SVN recently and am happy with it as a "CVS
done right", or we could use any of the new crop of distributed systems.
I've been absolutely loving working with darcs but have been running in
to annoying corner cases with spinning & never terminating a little too
often to recommend its use here.