[zeromq-dev] Proposal for 2.0.7: Cleaning up the ZMQ_* constants
mato at kotelna.sk
Thu Apr 15 18:43:01 CEST 2010
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
ZMQ_POLL should become ZMQ_CTX_POLL, since it is specific to zmq_init()
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
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:
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.
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
More information about the zeromq-dev