[zeromq-dev] patch to add zmq_msg_flags()

[Chuck Remes]

On Oct 29, 2011, at 1:57 AM, Martin Sustrik wrote:

> Hi Chuck,
> 
>> I wrote the source patch, docs and a test to verify the behavior. It is signed off according to the rules posted at [1].
>> 
>> Comments?
> 
> As discussed before, this is good but backward incompatible change. I 
> would suggest sending an email describing what it does, how it breaks 
> current semantics and asking people to comment on whether it should go 
> to 3.0 or whether it should be staged for later inclusion.

Martin,

I need a little help from you (or someone else on this list) to explain how this change breaks current semantics.

1. Since this project follows "semantic versioning" rules as described here (http://semver.org/), I took a look to see how this change would be classified. I believe it falls under rule #7 which only requires a minor (major.minor.patch) change.

> Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API. It MAY be incremented if substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes.

This new function call is an addition to the API, but it does not break *backward* compatibility. It does not remove any functionality as far as I can tell. A user may choose to continue using zmq_getsockopt() with ZMQ_RCVLABLE/ZMQ_RCVMORE to retrieve the flags; this functionality is unchanged.

2. In an earlier response to my original thread (3.x zmq_msg_t change proposal) you described how this idea would break backward compatibility. 

> 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.

As you said, the patch does not clear the flags from the message object before returning it to the user. This is necessary so the user can interrogate the object for its flags. However, when sending this *same* message, the zmq::socket_base_t::send() function now clears the flags before transmitting the data over the wire. I believe this maintains *current semantics* without introducing any breaking behavior. If I am wrong, please explain so I can understand it.

cr