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