On Tue, Jul 27, 2010 at 10:57 AM, Martin Sustrik <[email protected]> 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 [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
