On Fri, Feb 6, 2015 at 9:41 PM, AJ Lewis <[email protected]> wrote:
> This doesn't address the use of having messages that don't need to be > decoded at each hop... Let me collect what I see as valid requirements here, from the entire thread: - a routing stack for multi-hop request-reply, which can be used without decoding the message - replacement of "identity" concept with something like "reply handle" - a simple message blob that reduces upstream costs for message handling - atomic send/recv methods that can potentially be made threadsafe - scatter-gather send/recv that allows zero-copy for efficiency - new higher-level client/server semantics that replace req-router-dealer-rep What we do not need to do: - move any zproto serialization into libzmq; this can happily live at higher layers - break or change any existing contracts, as everything works and is stable These can all be satisfied, IMO, with some new protocol designs and new client/server sockets, and new API classes. And we can do this slowly, over time, perhaps with faster experimentation in stacks like NetMQ that are more fungible. -Pieter _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
