Hi Brian, > * It is not clear why there are changes that change the API to merely > rename things (zmq_send/zmq_recv/ZMQ_NOBLOCK). I think the existing > names are sufficiently clear that it doesn't make sense to change > these (unless there something else at play).
These are POSIX-related changes. The goal is to make 0MQ API coherent with future kernel implementations of the stack. > * I have posted elsewhere that I think it is important to keep > zmq_device around. I want to clarify this. I think the > *functionality* is important, but am not attached to the existing API > for devices. It is definitely a part of zmq that could be improved. > But, I think the goal in 3.0 is improvement of this API, not removal. > I think this type of thing does belong in the core API and not a > separate code base. The problem, I think, is that you can easily think of tons of different devices, each providing different functionalities. The question then is: Which one should then be part of 0mq core? The minimal one? And if so, should any new features be systematically rejected on the basis of breaking minimality? If so, is the built-in device intended to be a training device for newbies to be migrated away from once the need for more complex functionality arises? Etc. Martin _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
