[zeromq-dev] Forwards compatibility from 2.1 to 3.0

Martin Sustrik sustrik at 250bpm.com
Mon Apr 11 13:12:55 CEST 2011


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



More information about the zeromq-dev mailing list