[zeromq-dev] [otish] "Why ZeroMQ"
mato at kotelna.sk
Tue Jul 27 12:17:22 CEST 2010
ph at imatix.com said:
> On Tue, Jul 27, 2010 at 11:36 AM, Martin Lucina <mato at kotelna.sk> wrote:
> > Please note that this only applies if you're using UPSTREAM/DOWNSTREAM
> > sockets to implement the "butterfly" design. There are other options where
> > the roles of each node are nowhere near as clear-cut as you make them out
> > to be.
> What are those other options? Please point me to them, the butterfly
> example is the only documented pipeline pattern I've seen.
There was an interesting use Martin Sustrik described at some point on the
mailing list (yeah, yeah, even I can't find it) which involved connecting
the pipeline back on itself. Of course, I'm sure you'll argue that makes a
node both a BF_CLIENT and BF_COLLECTOR...
Then there are the "data diode" people using UPSTREAM/DOWNSTREAM sockets
exclusively for their unidirectionality, but I presume their topologies are
all top secret :-)
> It does not matter what naming scheme there is as long as it is
> consistent and predictable. Are you suggesting the current names are
> NOT confusing? Or that education and documentation are a replacement
> for unsurprising, predictable, consistent names?
I am suggesting that once I actually started using 0MQ in anger the names
all made sense. I'm sure they could be made better, but at least to me it
seems there is a hell of a lot of other stuff (um, you promised a tutorial
ages ago?) which would be more useful right now than discussing socket
> "In practice it would cause more harm than good" is one of those
> statements that needs backing with examples. Right now we have lots
> of examples of the current naming scheme causing confusion.
Lots? I'm sure there's a happy (and therefore silent) group of users out
> > You are not taking into account the fact that the 0MQ API was designed
> > explicitly to look like POSIX sockets, with the long term view of
> > integration into kernel space, which is not the same as desiging an API
> > from scratch.
> ? I do not think this part of the 0MQ API has anything to do with POSIX.
I was merely reacting to your complaint about the API not being "documented
in advance", but I think that's really beside the point here.
More information about the zeromq-dev