[zeromq-dev] libzmq v4.0.5

Pieter Hintjens ph at imatix.com
Fri Sep 26 10:26:44 CEST 2014

I'm going to cut this thread down and reply minimally:

> And since you asked for it let me complain about this here. :) Maybe
> http://api.zeromq.org/4-1:zmq-sendmsg could be removed from the table
> of contents (or moved to a deprecated section in the table of contents
> so it remains for reference).

See "man zmq".

The website needs fixing, yes.

> 1) Then why isn't this done for the "now blocks" issue to preserve
> API/ABI compatibility? Or for the monitor socket?

Because no-one cared enough to ask this question at the time, and
enforce the rules.

> 2) "Check the *many* ROUTER socket options." That was my point. Over
> time such options get more and more and more. So your code gets longer
> and longer. You can't just open a socket and get to work anymore.

That simply isn't true. Show me code in Zyre or zgossip or elsewhere
that gets "longer and longer".

> A  : zmq_send
> A' : zmq_sendmsg
> A'': zmq_msg_send

And when, say, ZAP or the monitor API is changing in parallel? How do
you force a single version on an API that is changing concurrently in
different areas?

> Currently you have A and A' and A'' all at the same time. There is no
> choice between them. They all exists, all need to be maintained and
> all can be used all mixed together in the same source. What you have
> is multiple APIs all mixed together. That is what I call "insane".

You raise "maintenance" as if that's an issue. It's not. zmq.cpp is
incredibly stable. There is almost zero cost to keeping the old APIs
around. They're not in the zmq man page. They aren't modified.

Yes, there's a documentation and upstream packaging issue. However
that would become much worse if you tried your versioning scheme.

> What the ZMQ_USE_VERSION (lets change that from FUSE) would do for us
> in that case is to hide insanity from the user

You keep using that word and yet your data is "I got confused when I
looked at the docs" (which is a valid yet not a sign of insanity

Anyhow, short / long answer: fork the thing, show us what you mean.
Discussion is boring. Show us code.

Here's a proposal: add a zmq_ctx_set () call that defines the API
version for the context. Make a ZMQ_API_V4 constant. Make this
block/disable all old calls. Make this set smarter defaults on all
socket types. Do those changes, then document them, explain them, and
make it all work in libzmq, CZMQ, PyZMQ, and the zillion other
projects that use libzmq. Then show how it's simpler.

This is the correct process, according to our contracts.

If you're not willing to do this, this discussion is moot. I'm
certainly not willing to do it and I've not heard anyone else
volunteering. I'm not interested in offering people more options and
more ways to get compile failures in the interest of "cleaning things
up". Been there, done that, the results are not good.


More information about the zeromq-dev mailing list