On Wed, Jul 28, 2010 at 3:36 PM, Pieter Hintjens <[email protected]> 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. > > Interesting, I have ben thinking about this lately as well. The reason I started to think about this is that there are a core set of capabilities that 0MQ sockets have like: * HWM handling (discard or block) * Outbound routing (multcast, load balance, identity based routing, etc., topics) * Inbound routing (fair queing) * Number of peers (1, many) * Directional (R, W, RW) * Sync/async, etc. All of these things could be options to a lower level socket object. This would allow the building of other socket types as well as the current types. BUT, I am worried that this is too much flexibility and that 90$ of the combinations don't make sense. So, to go this direction, I think we would have to have a really strong reason to do so. What could people do, that they actually need to do, that they can't now? > 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. > > Yes, whatever happens in 0MQ3, I hope that the user/dev facing APIs can remain the same or evolve gradually. 0MQ has gained a ton of momentum and we and others are now building real apps with it. While I am all for incremental evolution of the API to improve features and address limitations, I think major API breakage or redesign would be a bad thing at this point....such as happened to AMQP with the 1.0 spec... > 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 > -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo [email protected] [email protected]
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
