Hi all, I believe this discussion misses what I wanted to say.
There are many issues mixed here: 1. Should 0MQ provide internal message parts? 2. Should 0MQ provide application-level message parts? 3. Expose the functionality as gather-scatter arrays? 4. Should the 0MQ-related parts of the protocol separate from application-level parts? Answer to 1 is yes (because of way REQ/REP works). Answer to 2 is yes due to the popular demand. Answer to 3 is no, to preserve backward compatibility. My point was that the answer for 4 should be "yes" and the fact that it is not so is unfortunate. Too late to fix that, anyway. I've tried with LABELs and failed. 0MQ is a stable product and bad design decisions are already baked in. Not much we can do about that. Martin On 22/01/12 20:51, Brian Granger wrote: > 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] > > > _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
