On Jul 28, 2010, at 6:36 PM, Pieter Hintjens wrote: > 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. >
Classic separation of policy and implementation -- provide orthogonal capabilities to construct systems based on patterns derived from usage and use cases. Sounds like set of formal GoF style Design Patterns would be sensible right about now, e.g. "The ØMQ Pattern Language : Design Patterns for High-Performance Networking" -- or some such. (Excuse me, I've got to dust off the ol' Christopher Alexander tomes now... :-) ) > -Pieter > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev Best, Matt _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
