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

Dhammika Pathirana dhammika at gmail.com
Fri Apr 16 03:59:39 CEST 2010


On 4/15/10, Martin Lucina <mato at kotelna.sk> wrote:
> All,
>
>  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.



>  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.
>
>  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.
>
>  -mato
>
>
>
>
>
>
>  _______________________________________________
>  zeromq-dev mailing list
>  zeromq-dev at lists.zeromq.org
>  http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



More information about the zeromq-dev mailing list