[zeromq-dev] Proposal for 2.0.7: Cleaning up the ZMQ_* constants
ellisonbg at gmail.com
Thu Apr 15 19:50:39 CEST 2010
I am not too excited about this change as the current API is pretty
well established and the new convention simply makes all of use type
more. But, I spend a lot of my time in the Python universe, where
"flat is better than nested." (I view the proposal as a sort for
On Thu, Apr 15, 2010 at 9:43 AM, Martin Lucina <mato at kotelna.sk> wrote:
> with the introduction of more send/recv flags (ZMQ_SNDMORE), socket options
> (ZMQ_RCVMORE) and the experimental device api (ZMQ_STREAMER et al) the ZMQ_
> namespace for constants is starting to look rather ad-hoc and crowded.
> There are two main motivations for doing the cleanup. Firstly, crowding
> everything under ZMQ_ leads to less room for future expansion. Secondly,
> it's nicer from the programmers point of view to be able to identify what
> area of the API a ZMQ_XXX constant is relevant to.
> In the interest of cleaning things up now rather than later
> I'd like to get some discussion on this started. What follows is a draft
> Infrastructure flags:
> ZMQ_POLL should become ZMQ_CTX_POLL, since it is specific to zmq_init()
> Socket types:
> Either leave them as they are now, since they are the basic building block
> of 0MQ, or optionally rename them to ZMQ_SOCK_XXX, so e.g. ZMQ_REQ becomes
> Socket options:
> This is the biggest group and also the most ad-hoc.
> Options which are applicable to all sockets ("core options") should be
> renamed ZMQ_SO_XXX. Options applicable to only certain specific transports
> should be renamed to ZMQ_TRANSPORT_XXX. This would give us the following:
> Core options:
> ZMQ_HWM == ZMQ_SO_HWM
> ZMQ_LWM == ZMQ_SO_LWM
> ZMQ_SWAP == ZMQ_SO_SWAP
> ZMQ_AFFINITY == ZMQ_SO_AFFINITY
> ZMQ_IDENTITY == ZMQ_SO_IDENTITY
> ZMQ_SNDBUF == ZMQ_SO_SNDBUF
> ZMQ_RCVBUF == ZMQ_SO_RCVBUF
> Specific to PGM:
> ZMQ_RATE == ZMQ_PGM_RATE
> ZMQ_RECOVERY_IVL == ZMQ_PGM_RECOVERY_IVL
> ZMQ_MCAST_LOOP == ZMQ_PGM_MCAST_LOOP
> ZMQ_SUBSCRIBE/ZMQ_UNSUBSCRIBE -- these are specific to ZMQ_SUB sockets
> only. I'm not sure how that could be reflected in their naming. Maybe
> just ZMQ_SUB_ADD, ZMQ_SUB_REMOVE?
> ZMQ_RCVMORE in that it is related to zmq_recv() would seem nicer as
> ZMQ_RECV_MORE. ZMQ_SO_MORE might also work.
> Send/recv flags:
> ZMQ_NOBLOCK -- stays as it is?
> ZMQ_SNDMORE -- as for ZMQ_RCVMORE, I'd prefer ZMQ_SEND_MORE.
> Another option with the above if we want to be really consistent is
> defining ZMQ_SR as a prefix for send/receive flags, which would give us
> ZMQ_SR_NOBLOCK, ZMQ_SR_MORE.
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com
More information about the zeromq-dev