[zeromq-dev] 3.x zmq_msg_t change proposal

[Chuck Remes]

On Oct 28, 2011, at 1:38 AM, Martin Sustrik wrote:

> Hi Chuck,
> 
>> While thinking through a few scenarios with DEALER/ROUTER (and
>> XREQ/XREP) in 0mq 3.0, it occurred to me that it doesn't make a lot
>> of sense for us to test the *socket* to see if a message part is a
>> label or not. The zmq_msg_t structure already has this information.
> 
> The problem is with zmq_send (void*, size_t, int) and zmq_recv (void*, 
> size_t, int) There's no way to return the ancillary data using these 
> functions.
> 
> I wanted to avoid POSIX-like ancillary data:
> 
> http://rfc-ref.org/RFC-TEXTS/3542/chapter20.html
> 
> If you are familiar with that API, you can see it's much more complex 
> that current 0MQ's getsockopt() API.

Yes, I can see that.

> In short, you can implement access to message flags via message object, 
> however, the old way of accessing it is still necessary.

Is it necessary to maintain the old way *forever* or can it be phased out over time?


> One additional concern: The change is not backward compatible. Current 
> implementation clears the flags when receiving a message part. Ie. when 
> you re-send it, it behaves like a separate message. It would be nice to 
> get rid of this behaviour, however, you need a consensus of users on the 
> backward incompatible change.

Now that I am digging through socket_base.cpp I see that it calls reset_flags() quite often to clear these things. I have no idea (yet) how to handle that in a backward-compatible way or if that is even possible.

Before I do anything, I will share my thoughts with the list and hopefully get some feedback.

cr