2011/6/19 Martin Sustrik <[email protected]>: > To build patterns on top of basic functionality, you need access to quite a > lot of underlying functions/events. Connection events, disconnection events, > queue depths, dropping of pending messages, explicit removing peer from the > socket, routing to a particular peer, signaling POLLIN and POLLOUT etc.
Aren't the same thing already happening right now, except exposed in somewhat different way. In fact, it seems like the requests are mostly like modifying a particular behavior of a socket (direction, send/recv pattern, routing strategy, back pressure behavior) without touching the other elements. Having to create a new socket type for each of the possible combinaison seems to me a recipe for bloating the library or accumulating fork if there is any dissention on the usefulness of the new socket type. > These functions/events have to be made available via API, which will over > time offer more and more functionality. Ultimately, the API would be > functionally equivalent to BSD sockets. At that point the "basic" layer can > be dropped and replaced by BSD sockets. Which will bring us from where we > wanted to get (BSD sockets + basic messaging layer + patterns) to where we > are now (BSD sockets + patterns). May be we are just talking about the same thing here: For me, I see ZMTP has the basic messaging layer. It could been augment to allow more distinction between messages, including control vs application message (the LABEL flag is just a step toward this), most of the current pattern would then be able to be implement over this. Just for example, let the socket layer only specify the back pressure behavior (drop/non-drop) and out routing strategy (fq/dist), and allow access to direct peer message addressing (both on reception and sending). Everything else could then be implement in the top layer with control message without having to divert the upper layer "pattern sockets" out of there normal use case, lowering the risk of incompatibility at the same time. Even connection events could be handle using "control" messages and timeout. Let me know what you think about it. Right now, I'm a bit confused for what I see as a dual-purpose design and have a hard time to specify correctly the collector pattern (and even an LRU pattern) without a clearer view on the future of ZMQ. Fabien _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
