[zeromq-dev] [otish] "Why ZeroMQ"

[Martin Sustrik]

Well, in any case, it cannot be implemented. Let's try to come up with 
something implementable :)

Martin

Pieter Hintjens wrote:
> On Tue, Jul 27, 2010 at 10:57 AM, Martin Sustrik <sustrik at 250bpm.com> wrote:
> 
>> Note that CLIENT and COLLECTOR are redundant as CLIENT is just a worker
>> that happens not to receive any messages and COLLECTOR is just a worker
>> that happens not to send any messages.
> 
> The redundancy is what makes it comprehensible.  If you look at the
> butterfly pattern you see that there are three roles: the node that
> originates the workloads, the nodes that accept the work, and the node
> that collects the results.
> 
> If you insist on reducing this to its minimum, you also strip out the
> role of the nodes IMO, and come to the rather meaningless "single
> socket that does it all but for technical reasons I need two sockets
> so let me invent two random names".
> 
> Which does not map to the actual use case, which causes confusion.
> There is no fault in using redundancy if it makes things more
> comprehensible.
> 
>> Which leaves us with a nice model with a single socket type...
> 
> No, that leaves you with nothing to hang your use case on.
> 
> Sink and source are better than the current upstream/downstream but
> still do not reflect the actual role that the node is playing.
> 
> To choose good names you must approach this from the point of view of
> the person using the pattern and ask, what does the user _expect_ that
> a socket type would be called.
> 
> This is why you should document APIs before implementing them,
> otherwise you push technical concerns like "I need two socket types to
> distinguish between the binding and connecting peers" into user space,
> which is totally the wrong way to design an API.
> 
> BTW the nomenclature proposed (which I don't defend, but just hold as
> an example of a properly unsurprising design) won't work unless the
> pattern name is included in the socket type.  "Client" is also perfect
> for the request/response pattern, better than "request" (which is the
> message type, not the role of the node).
> 
> Sorry to rant, but the inconsistency in these names just hurts and
> will keep hurting until it is properly resolved.
> 
> -Pieter
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev