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

Brian Granger 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
pseudo=nesting).

Cheers,

Brian

On Thu, Apr 15, 2010 at 9:43 AM, 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.
>
> 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
>



-- 
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 mailing list