I should also note that I don't consider multipart messages an unfortunately accident. In my mind they are one of the killer features of ZeroMQ that allows it to scale and achieve high performance with large amounts of data. Before ZeroMQ, we had struggled for years with the lack of good multipart messages in the network protocols we were using. The idea and implementation are brilliant, and Martin definitely gets the credit for this (even if he may regret it...).
Cheers, Brian On Sun, Jan 22, 2012 at 11:43 AM, Brian Granger <[email protected]> wrote: > On Sun, Jan 22, 2012 at 7:48 AM, Pieter Hintjens <[email protected]> wrote: >> On Sun, Jan 22, 2012 at 9:36 AM, john skaller >> <[email protected]> wrote: >> >>> The problem is like this: if you use say an array, you can put the >>> pieces into it in any temporal order. This allows you to write >>> simple code. >> >> This is an accurate statement of the problem, but the answer doesn't >> lie in the low level API. In CZMQ, for instance, we solve this by >> treating a "message" as a multipart object (composed of frames), which >> we can send and receive in one step, and work with separately, as an >> array, list, stack, whatever. It's one of the abstractions I proposed >> binding authors should take seriously[1], precisely because the way >> applications need to work with frames doesn't match the 0MQ low level >> API. More accurately, there is no single application semantic, there >> are several. >> >> So solution: make the language binding smarter. > > In the Python bindings, dealing with multipart message is nearly > trivial most of the time. They are represented as Python lists and > can be sent/recv'd as easily as a single message part. The only cases > where you need to deal with each message part separately is if you > need to treat each message part differently - unicode handling > differently, some copy/non-copy, etc. > > Cheers, > > Brian > >> -Pieter >> >> [1] http://www.zeromq.org/topics:binding-abstractions >> _______________________________________________ >> zeromq-dev mailing list >> [email protected] >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > -- > Brian E. Granger > Cal Poly State University, San Luis Obispo > [email protected] and [email protected] -- Brian E. Granger Cal Poly State University, San Luis Obispo [email protected] and [email protected] _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
