[zeromq-dev] Moving to 0MQ/3.0, yes or no?

[Martin Sustrik]

Hi Pieter,

> Is there any documentation for the 3.0 API changes?

All the changes are properly reflected in the docs except for 
zmq_send/recv/sendmsg/recvmsg thing which required more text and seemed 
to be still under discussion.

> I'm noticing that zmq_recvmsg() now returns a positive value on
> success, presumably the number of bytes read. Are callers supposed to
> use this information? Do you still store the received size in the
> message as well?

Yes and yes. It's standard POSIX behaviour. With recvmsg() you can use 
any of the two values, as you see fit. They are the same. As for recv() 
the returned value is the size of the received message. That applies 
even if the message exceeded the buffer and was truncated. This is UDP 
behaviour and can be extended in the future be introducing MSG_PEEK.

One additional comment is that in POSIX the return type from these 
functions is ssize_t. The reason I've used int at the moment is that 
return value on Windows is int and ssize_t is not even defined :|

The alternative would be to do something like:

#if defined ZMQ_HAVE_WINDOWS
#define ssize_t int
#else
#include <sys/types.h>
#endif

Thoughts anyone?

> Also, do you intend to provide the new ZMQ_ROUTER, ZMQ_DEALER names in
> 3.0? What's the status with this? We did discuss this extensively on
> the list and on IRC, and came to consensus, with you involved, but the
> new names aren't in 3.0 afaics.

I propose to create a new messaging pattern (in other words, clearly 
separated vertical segment of the stack) to deal with "email" 
(send-to-address) scenarios. At the moment the new socket types can be 
simply defined to be duplicates of existing XREQ and XREP sockets. Later 
on, they can diverge.

Martin