On Sun, Feb 8, 2015 at 12:53 AM, MinRK <benjami...@gmail.com> wrote:
> I guess the problems I identified that it solves weren't really problems,
> then.
Where in the email below are you identifying the problems that the
experimental split of multipart messages into labels + parts was
trying to solve?
-Pieter
> If I recall correctly, libzmq-3.0 (or was it the old 4.0 experimental
> branch?) preserved multi-hop while separating routing from content by
> making the routing id a sequence rather than a single value. That way,
> it seems that the same push/pop behavior that happens on a ROUTER-DEALER
> device today could still work on CLIENT-SERVER. The push/pop would be
> happening on the routing stack instead of message content.
>
> If a message were something like:
>
> {
> frame_t frames[];
> int nframes;
> routing_id_t route[];
> int nroutes;
> }
>
> it would seem that you could have multi-part content (selfishly, in the
> way that affects me - messages composed of non-contiguous memory),
> multi-hop routing, and send it all with a single `zmq_send_newfangled`
> call, allowing future attempts at making `zmq_send_newfangled` a
> threadsafe call.
>
> There may be reasons this would be super gross and horrible, but it's an
> idea, anyway.
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
