[email protected] said: > 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.
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. The same applies for request/reply, at least when using XREQ/XREP. It is not required that "the node using XREQ" is "the client" or "the node using XREP" is "the service", see for example Brian Granger's message as of a few days ago about "clever uses of XREQ/XREP", all of which are legitimate. In retrospect, my view is that while "naming the sockets after the nodes role in the topology" seems like a good idea at first sight, in practice it would cause more harm than good. > 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". Well, the reason we ditched the idea of a WORKER socket is that it does seem to be technically impossible to implement in a way that fits with the existing APIs. Perhaps you have a consistent proposal how to implement it? > 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. 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. > 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). See above. > Sorry to rant, but the inconsistency in these names just hurts and > will keep hurting until it is properly resolved. Maybe just get over it, use the product, and be happy? :-) -mato _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
