[zeromq-dev] Feedback on new PATCH socket

[Fabien Ninoles]

> > However, one way to be more transparent is to mark a frame as being
> > "added" to the original message instead of using the empty delimiter.
> > This will allow REQ/REP to work directly without change.   The flag
> > need to be pass between sockets however (just like the MORE flag) and
> > so this is not compatible with the current queue device.   However, if
> > the API were setting the flag inside the msg_t struct, this would
> > have been completly transparent, will remove some potential beginner
> > bug (like sending a RCVMORE msg without the SNDMORE flag in a device)
> > and, I'm pretty sure we can make it semantically meaningful (by
> > calling it FOLLOWED for example).
> 
> I would love to replace multi-part messages by message+labels system, 
> however, this is not backward compatible and thus unlikely to happen in 
> 0MQ. You will probably find it in the future implementations such as 
> Linux kernel implementation.

How this break backward compatibility ?  Frames already have flags, and you can keep the old API for the MORE flags or add a KEEPFLAGS option in the zmq_send API.  This will allow future implementation to be even more robust (on the principle of "If you don't know it, don't touch it."). Right now, there is no way to ensure that a ZMQ application can preserve all flags set on a message, which is a big handicap for forward compatibility.

Fabien