On Tue, Jul 27, 2010 at 11:36 AM, Martin Lucina <[email protected]> wrote:
> 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. What are those other options? Please point me to them, the butterfly example is the only documented pipeline pattern I've seen. > The same applies for request/reply, at least when using XREQ/XREP. XREQ/XREP were not in the list. They're low level socket types that can be (ab)used in various ways. > 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. It does not matter what naming scheme there is as long as it is consistent and predictable. Are you suggesting the current names are NOT confusing? Or that education and documentation are a replacement for unsurprising, predictable, consistent names? "In practice it would cause more harm than good" is one of those statements that needs backing with examples. Right now we have lots of examples of the current naming scheme causing confusion. > 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? Not offhand, no. > 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. ? I do not think this part of the 0MQ API has anything to do with POSIX. > Maybe just get over it, use the product, and be happy? :-) You miss the point, Mato, which is that people using the product complain about it being confusing. Feel free to propose an answer to that (and BTW, "more documentation" is probably the wrong one.) -Pieter _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
