[zeromq-dev] [PATCH] Add msg_t::label flag

[Martin Sustrik]

Hi Fabien,

>> It's matter of good design. Message envelope dispersed throughout the
>> message violates clean layering. Additionally, it is a nightmare to
>> parse at wire speed.
>
> Ack.  I attach a new patch with the comment.  However, I don't think
> the code should
> check for this in all occasions, no ?

Is there any reason why it should not?

>> The orthogonality is what should be deliberately avoided here. Note that
>> LABEL flag and MORE flag live at different layers. LABEL flag is 0MQ
>> flag, while MORE is an application flag. You can think of it as
>> user-defined multi-part message being taken as atomic unit and labeled
>> with various labels by 0MQ. The two should never overlap.
>>
>> Unfortunately, backward compatibility concerns force us to mix the two
>> flags in a single layer, which makes the above non-obvious.
>
> Right on this.  I was thinking about this for the collector, but can't
> find a way
> to completly removed the flag from the user without giving up the frame division
> of ZMQ messages.

Not doable IMO. I should have used scatter/gather arrays instead of 
multipart messages from the beginning. Too late to fix that now. We'll 
have to live with it.

> May be the next generation of ZMQ API shoud avoid access
> to frames internally; basically, pushing all the frames on a msg_t and
> have an api to
> access only permitted frames ?

Note that non-X-style sockets already do something like that. Say REP 
socket removes all the labels from the request before passing it to the 
user.

X-style sockets are meant to be the lower layer of the stack, where the 
labels are visible.

Martin