[zeromq-dev] Proposal for 2.0.7: Cleaning up the ZMQ_* constants

[Martin Sustrik]

Dhammika Pathirana 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.
>> 
> Why not define these as enums?
> Then the API is much cleaner and we don't need to lookup man pages.

0MQ API tries to mimic Berkeley sockets API thus defines rather than enums.

>>  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
>>  proposal:
>>
>>  Infrastructure flags:
>>
>>  ZMQ_POLL should become ZMQ_CTX_POLL, since it is specific to zmq_init()
>>  only.

I thought of dropping this flag completely and allowing poll by default. 
Doing so would add ~2us to the latency though.

>>  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
>>  ZMQ_SOCK_REQ.
>>
>>  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
>>
>>  Special/undecided:
>>  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.

As for socket options it should be noted that BSD sockets define the 
constants according to the layer they are used at (consider SO_LINGER 
vs. TCP_NODELAY.

Following this logic 0MQ-specific socket options would be simply 
prefixed by ZMQ_.

There are several exceptions though: PGM_RATE and PGM_RECOVERY_IVL at 
the moment. If possible we should mimic option names as used in RFC3208.

ZMQ_SNDBUF, ZMQ_RCVBUF => SO_SNDBUF, SO_RCVBUF.

It's not obvious how to prevent collisions between 0mq-defined and 
OS-defined constants in such a case.

Etc.

Martin