[zeromq-dev] Important: backward incompatible changes for 0MQ/3.0!
ph at imatix.com
Mon Mar 21 17:23:29 CET 2011
On Mon, Mar 21, 2011 at 4:57 PM, Martin Sustrik <sustrik at 250bpm.com> wrote:
> The changes (at least those I am aware of atm) will affect C API, but
> all the other language bindings will probably remain stable. That should
> make the transition simpler.
I'm going to propose an independent C binding which will sit above the
core C API. This will make C applications better isolated from these
changes and provide portability across 2.0 and 3.0.
> There's a change to wire format suggested. That would make 0MQ/2.x.x
> components unable to speak to 0MQ/3.x.x components.
Can there be a version detection to at least warn users of this?
> you should be able to use standard POSIX syntax:
> nbytes = zmq_send (s, "ABCD", 4, 0);
> assert (nbytes == 4);
Send is easy since a TCP stream and 0MQ message both look the same at
sending. I'm more concerned about recv, since the two semantics are
totally different there. Do you have a sketch for the recv call?
> 3. Change zmq_poll's timeout value unit from microseconds to
> milliseconds to make it coherent with POSIX poll.
Experience from the Guide is that milliseconds are easier to work
with, and also more portable.
> 7. Devices should be moved out of ØMQ core. The devices are pretty
> independent from the core.
The stand-alone devices are already gone from today's 2.1 package.
They were undocumented and had resisted at least two attempts at
improvement (Jon Dyte and myself both submitted patches for better
versions, those patches were never included).
> 8. On-disk swap should be made a device rather than an internal feature
> of ØMQ sockets. Persistence is a hard problem and should be solved
> independently of 0MQ core which is basically a networking library.
Sounds good - there is demand for added functionality such as recoverability.
> 9. C++ binding should be removed from the core. All the other language
> bindings are separate projects. There's no reason to treat C++ in a
> special way.
The more powerful reason is that any layer which is part of the core
resists improvement. We have seen this with devices, it's also the
case with the C++ binding.
> 10. I would like to remove ZMQ_PAIR pattern altogether, however, Pieter
> uses it in the guide, so he proposes to instead limit it to inproc
> transport which is the only use case there. Please, if you are using
> PAIR, whether over inproc or tcp or whatever, scream now!
I'm screaming. PAIR sockets are the natural way to connect a parent
and a child thread when you use threads to break a problem up. They
work nicely over inproc, and though there are a few open issues on
them, nothing that affects their real use.
> For those interested in 0MQ wire format, there are two proposed changes
> at the moment...
Please, let us start by documenting the new format, then implement it.
We really need a proper independent RFC for the WLP.
For everything else, +1, I'm looking forwards to 3.0.
It's worth saying, though Martin didn't say this, that 2.1 will be
maintained and kept stable for a long time (12-18 months).
At this stage we don't plan a 2.2 release.
More information about the zeromq-dev