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 <[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 _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
