[zeromq-dev] Governance of language bindings

Martin Sustrik sustrik at 250bpm.com
Tue Jan 26 13:53:03 CET 2010


Adrian, Jon, Toralf, Peter,

Thanks for your thought on the issue!

It seems that everyone is in favour of the proposal, so let's move on 
with the idea.

One thing to keep in mind though is the usability of the product. Once 
we have packages for all major distributions, strict decoupling of 0MQ 
core and language bindings would be the best solution.

At the moment though it would make using 0MQ more complex: download the 
core, build it, download the language binding, build it etc.

Thus I would rather move to the goal gradually. Haskell binding, as it 
is still clearly decoupled from 0MQ core makes a perfect candidate to 
start with. Later on we can decouple Common List binding which is glued 
to 0MQ core in somehow forceful fashion. Still later on we can decouple 
Ruby, then Python etc.

We need to provide some information to guarantee good usability of 
language bindings:

1. Source repository location
2. Build instructions
3. Package for language's native packaging system (CPAN, ASDF, hackage 
etc.) if any.
4. Packages for individual OS distributions, if any.
5. Documentation in native format (Javadoc etc.)
6. Mailing list - we can use zeromq-dev for now.
7. List of binding authors and/or binding maintainer.

Toralf, we should put this together to make a template for all language 
bindings. It can be presented as a wiki page, in form of a table, 
whatever. To be discussed.

Some comments on your emails follow:

 > To put in my two cents, I think 0MQ should ship with C/C++ only.

I can even imaging 0MQ core providing ABI only, with C and C++ bindings 
being semi-separate projects.

 > From a packager / Linux distributor's perspective: agreeing on a 
stable API
 > (ideally ABI, even) would be very welcome for multiple reasons:
 >
 >  * having multiple language bindings in one package requires at least 
basic
 > knowledge of  library / extension packaging for all these languages 
(or not
 > compiling all languages in the distribution packaging, but that'd be a
 > shame.)  This makes packaging harder.
 >
 >  * Dependency hell: probably Debian specific through our workflow with
 > "unstable" and "testing" distributions and the way how packages are run
 > through this system: a language bindings package may become a logjam, 
tying
 > version transitions of completely unrelated languages together. 
Multiple
 > independent packages that depend on a core library reduce this 
considerably.
 >
 >  * build time: Debian supports a few architectures with quite weak CPUs
 > (although since 68k has been demoted to an unsupported port, the 
problem has
 > become a bit smaller.  ARM and MIPS are still not supercomputers, 
thogh.)
 > Again: independent packagees should result in fewer versions per 
langauge
 > binding, so fewer builds to fix bugs.  (If ruby is upgraded, only the 
ruby
 > package has to be rebuilt against the newer ruby etc.)

This only makes the original argument more persuasive. I think we have 
too many reasons to decouple the language bindings not to at least try it.

As for API/ABI thing, I would vote for ABI compatibility with the 
perspective of old versions of language bindings still working with 
newer version of 0MQ core. This would allow install new versions of 0MQ 
without the need to recompile the applications running on top of it.

One more comment: Decoupling the language bindings would allow for 
looser licensing model. The bindings would have to conform with LGPL 
license of the underlying core component, but they themselves would be 
free to use any compatible licensing scheme.

Martin






More information about the zeromq-dev mailing list