On Tue, Jul 27, 2010 at 2:36 AM, Martin Lucina <[email protected]> wrote:
> [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. > > +10^100. > > 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 > -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo [email protected] [email protected]
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
