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 _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
