[zeromq-dev] Important: backward incompatible changes for 0MQ/3.0!
sustrik at 250bpm.com
Tue Mar 22 08:26:06 CET 2011
On 03/21/2011 05:23 PM, Pieter Hintjens wrote:
> 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?
Definitely in version 3.0 and further. We'll see whether it's possible
to detect 2.x.x style connection.
>> 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?
I would mimic UDP. I am open to suggestions though.
>> 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).
Yes. They were freezed and marked for removal for a long time. Till now
I couldn't remove them to retain backward compatibility but now the time
>> 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.
Yes. I know you are using it with inproc. What I'm interested in is
whether anyone else is using it with TCP or IPC and thus, whether PAIR
can be restricted to inproc.
> Please, let us start by documenting the new format, then implement it.
> We really need a proper independent RFC for the WLP.
Right. My idea right now is to replace the single "identity" message by
a multipart message, so that multiple propoerties can be passed instead
of a single one.
Btw, note that 0mq socket type can't be changed from void* to int. I
wanted to do that myself but then I realised that the file descriptor
table is part of the context rather than global and thus you would have
to pass both context pointer and int:
zmq_send (context, sock, "A", 1, 0);
More information about the zeromq-dev