On Jul 27, 2010, at 10:40 AM, Pieter Hintjens wrote:

> On Tue, Jul 27, 2010 at 3:30 AM, Matt Weinstein
> <[email protected]> wrote:
> 
>> I've been using ZMQ_STREAM_SOURCE and ZMQ_STREAM_SINK.
>> There's still that "from which perspective?" problem.
> 
> It would be more consistent IMO to always name sockets after the role
> that the node plays.  

I am not really sure about this, wouldn't it be best to name the socket after 
the role the socket plays? 

For example, in a butterfly example the worker nodes have two types of socket 
they collect from the upstream and push their info downstream. This clearly 
shows the unidirectional flow of messages. 

I don't think SINK or SOURCE is a better naming as well. In a pipeline pattern 
a worker node is never the real source or the sink and it becomes more 
difficult to understand the grand scheme. This means for example that in a 
worker node you will have to receive on the SINK socket and send to the SOURCE 
socket. Sounds counter-intuitive to me.

> Now, request/response are named after the type
> of message, publish/subscriber after the role of the node, and
> upstream/downstream are perversely named after the role of the
> /receiving/ node.

Well, I think that the current naming is closely tied to the message pattern 
and to be honest I think that is the only sensible way to do it. 

Ie, req/rep says something about the flow of message through the socket not 
directly the message it self (as it can be both a response or a request). The 
same goes for pub/sub and up/down. 


> This is not about requiring paradigm shifts or better documentation,
> it's about using consistent names that provide some kind of model the
> poor developer can depend on.
> 
> The names Mato and I proposed for the pipeline pattern were:
> 
> ZMQ_BF_CLIENT, ZMQ_WORKER, ZMQ_COLLECTOR

I really think these would cause LOTS of troubles. Even in this specifically 
example you mostly have a server that produces items to be named client. 

Or take a look at the req/rep example, it isn't that difficult to imagine a 
protocol where the server initiates a request to clients. Where the node naming 
would turn it upside down.



_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Reply via email to