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 <[email protected]> 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 > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo [email protected] [email protected] _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
