On Wed, Jul 28, 2010 at 4:30 PM, Serge Aleynikov <[email protected]> wrote:
> You're certainly not the only one having trouble with the naming of > UPSTREAM/DOWNSTREAM sockets. Every time I think this notion is settled > in my head, if I stop thinking about it and come back to it in a few > days I have the same trouble in identifying the roles, which to me > clearly indicates of a poor naming choice. I think this is just because you need to think in terms of the topology to understand all the patterns except for pipeline, where you need to think in terms of that node alone. > However, maybe the problem is not just with names but with the fact that > the 0MQ project tries to be too ambitious in squeezing many concepts > into a single layer of the stack? There is a reason OSI is made up of 7 > layers where each has its own role and API. That was IMO because there were 8 committees. One had to be in charge. :-) > I don't mean to criticize the design too much at this point as I am sure > there's a reason for 0MQ architecture being done the way it's > implemented, but this lack of role separation in design is likely what's > causing much of confusion. Perhaps if the design treated sockets as > identifiable endpoints more explicitly, and had another layer for > defining communication patterns with a separate API, there would be less > trouble with concepts? This is the discussion Martin and I have been having about what 0MQ/3 might look like. There are use cases (such as authenticated data distribution, or indeed any custom pattern) where we want the whole 0MQ stack except routing. If 0MQ exposes the connections individually, then all patterns could be built on top of the core. Take this a step further and we could create an abstract socket type, e.g. 0MQ_RAW, which gave us full control over every aspect of the pattern in a runtime configurable manner. I.e. what's the exception strategy, what's the queuing strategy, is there an identity added yes/no, customized filtering, customized routing. All this could be layered on top of raw 0MQ sockets in such a way that the existing socket types become a pretty thin layer, easily extended with custom code. However... while this may appeal to those of us who like to make things... it would IMO be a Bad Idea to expose this to normal 0MQ users except carefully wrapped up as the existing socket types. Abstraction is harder to understand than concreteness. We learned this lesson with AMQP which does not give you patterns but instead building blocks that you must glue together to make patterns. The flexibility seems fantastic but in fact makes even the simplest work quite delicate. You can create 50-odd patterns with AMQP but only 4 or 5 make any sense at all. To conclude: * The confusion over the pipeline socket types can IMO be fixed with a rename that conforms to a topological view. ZMQ_SOURCE / ZMQ_SINK or ZMQ_FANOUT / ZMQ_FANIN seem to work topologically. * We continue to think about splitting 0MQ into a raw socket layer plus pattern layer. It may be possible to add raw sockets to 0MQ without major changes to existing socket types, and experiment with this for a while. -Pieter _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
