[zeromq-dev] multi-part messages

john skaller skaller at users.sourceforge.net
Mon Jan 23 03:40:43 CET 2012

On 23/01/2012, at 10:38 AM, Martin Sustrik wrote:

> Hi all,
> I believe this discussion misses what I wanted to say.
> There are many issues mixed here:
> 1. Should 0MQ provide internal message parts?
> 2. Should 0MQ provide application-level message parts?
> 3. Expose the functionality as gather-scatter arrays?
> 4. Should the 0MQ-related parts of the protocol separate from 
> application-level parts?
> Answer to 1 is yes (because of way REQ/REP works).
> Answer to 2 is yes due to the popular demand.
> Answer to 3 is no, to preserve backward compatibility.
> My point was that the answer for 4 should be "yes" and the fact that it 
> is not so is unfortunate.

I see no technical reason that you cannot *add* an array based interface:
two extra functions.

Having done that you could deprecate the old interface.

In 4.x you can remove it from the core API. It can still be supported
by a "legacy" API. After all the "legacy" API would simply populate
the array and the call send function (and the reverse for recv).

Alternatively .. the array API would just call the legacy interface :)

So the only real issue is what you document.

Anyhow I can live with the existing API  .. I don't write C unless
absolutely necessary and Felix, C++, Python and other bindings
can already do as suggested above (and it seems Python already does).

Just as a matter of curiosity .. "how much"  0MQ use is from C?
C++? Other languages? [The question means: is the C API 
primarily for application programming, or it there primarily
to support bindings to better languages?]

john skaller
skaller at users.sourceforge.net

More information about the zeromq-dev mailing list