I am really not fond of renaming the sockets other than UPSTREAM/DOWNSTREAM. Every alternate naming scheme I have seen has just as many (or more!) problems as the existing one and uses longer names that are a pain to type. In interactive languages like Python, you end up typing these names a lot, so length matters. Tab completion helps, but not much when there are prefixes like SOCK and REQREP.
Here is how I look at names like this: Imagine that understanding the various socket types is like a key/value store in our heads. In this picture, the KEY is the name we use to refer to the socket types and the VALUE is our full understanding of the socket types that includes all of the subtle details. For example: REQ (key) = sends requests to REP socket, uses SRSRSR pattern, Load balanced and last peer strategies. (value) Most importantly, KEY != VALUE. That is, the name we use to refer to each socket does not have to include all the information about the socket, it merely has to be a unique identifier that is not confusing. The longer naming schemes feel like they are trying to put the VALUE into the KEY, i.e., all of the details of the socket into the name of the socket. When a name represents a complex set of details, certain things are important: * The name should be short, unique and have something to do with the underlying details. The current names do that, with the exception of UPSTREAM/DOWNSTREAM which are ambiguous. * The name should not change. It takes a lot of work to learn all of the details of the 0MQ sockets. For example, I spent a long time learning/remembering all of the things that XREP/XREQ socket do. Having longer names would not have helped in any way. If these names change, everyone who has learned the details of the various socket types will have to relearn these associations, increasing the mental load required to use 0MQ. A few specific comments are below. On Tue, Jul 27, 2010 at 8:55 AM, Oliver Smith <[email protected]> wrote: > Pieter's list: > > http://www.zeromq.org/draft:socket-type-names > > - ZMQ_SOCK_REQREP_CLIENT (aka ZMQ_REQ). > - ZMQ_SOCK_REQREP_SERVICE (aka ZMQ_REP). > > Any usage of the words client/server/service is horribly confusing in the 0MQ context. This is because for many people server/client refers to which process binds and which process connects. Because the bind/connect in 0MQ is independent of the REQ/REP direction, this is just confusing. If you gave all of us a picture of various 0MQ based applications and asked the question, "which is the server and which is the client" I expect you would get a perfectly random distribution of answers. > > - ZMQ_SOCK_REQREP_CLIENT_ASYNC (aka ZMQ_XREQ). > - ZMQ_SOCK_REQREP_SERVICE_ASYNC (aka ZMQ_XREP). > > Same issue of client/server/service. > > - ZMQ_SOCK_PUBSUB_PUBLISHER (aka ZMQ_PUB). > - ZMQ_SOCK_PUBSUB_SUBSCRIBER (aka ZMQ_SUB). > > This seems quite redundant. I don't understand why PUB/SUB is not clear enough. > > - ZMQ_SOCK_PIPELINE_STDIN (aka ZMQ_PIN). > - ZMQ_SOCK_PIPELINE_STDOUT (aka ZMQ_POUT). > - > > I do think these sockets should be renamed, but these alternatives seem very verbose. I like some of the other, shorter ones that have been given. > - ZMQ_SOCK_EXCLUSIVE_PEER (aka ZMQ_PAIR). > > Again, I don't see how the long name communicates anything more than the current one. > My $0.01 (I'm too cheap to go the whole $0.02 just yet ;) > > Primarily: using stdin/stdout may cause naming conflicts and confusion -- > they are only borrowing from the concept of stdin/stdout, they are in no way > related. Plus we don't want someone to misunderstand them as the default > sockets for zmq. > > ZMQ_SOCK_REQREP_GENERATOR (aka ZMQ_REQ, the requester) => > zmq.sock.reqrep.generator > ZMQ_SOCK_REQREP_BROKER (alias for ZMQ_REP, the responder) => > zmq.sock.reqrep.broker > ZMQ_SOCK_REQREP_GENERATOR_ASYNC (aka ZMQ_XREQ) => problem > ZMQ_SOCK_REQREP_BROKER_ASYNC (aka ZMQ_XREP) => problem > I think "broker" is not an accurate representation of a socket and has too many connotations in messaging (that of a central process that manages messages). > > ZMQ_SOCK_BROADCAST_PUBLISHER (aka ZMQ_PUB) => zmq.sock.broadcast.publisher > ZMQ_SOCK_BROADCAST_SUBSCRIBER (aka ZMQ_SUB) => > zmq.sock.broadcast.subscriber > ZMQ_SOCK_PIPELINE_OUT (aka ZMQ_POUT) => zmq.sock.pipeline.out > ZMQ_SOCK_PIPELINE_IN (aka ZMQ_PIN) => zmq.sock.pipeline.in > ZMQ_SOCK_EXCLUSIVE_PEER (aka ZMQ_PAIR) => zmq.sock.exclusive.peer > > > - Oliver > > > _______________________________________________ > 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
