On Mon, Mar 21, 2011 at 08:57, Martin Sustrik <[email protected]> wrote: > Hi all, > > As for move to 3.0, the plan is to accomplish it in several steps: > > 1. Make all backward incompatible changes -- this phase should be done > as fast as possibly to minimise the pain. > > 2. Gradually implement new functionality. Add juicy new pieces to > balance the pain caused by phase 1. > > 3. In parallel, binding maintainers can start making bindings work with > 3.0. To minimise the work we can possibly deliver a compatibility header > that translates 2.x.x-style calls to 3.x.x-style calls. Unfortunately, > there's not much to do to simplify the upgrade for bindings that use ABI > rather than API (CLR and Common Lisp AFAIK). > > 4. Afterwards, the users can start gradually shifting to 0MQ/3.0. > > Some notes: > > The changes (at least those I am aware of atm) will affect C API, but > all the other language bindings will probably remain stable. That should > make the transition simpler. > > There's a change to wire format suggested. That would make 0MQ/2.x.x > components unable to speak to 0MQ/3.x.x components. > > Now, let me list the backward incompatible changes I am aware of. Note > that once the change is done, the new API won't change for a long time > (years), so if there's something you think should be changed, shout out > *now*. > > 1. Simplify the send/recv API for the cases where's there's no need for > zero-copy. Make the API POSIX-compliant at the same time. In short, > instead of: > > zmq_msg_t msg; > rc = zmq_msg_init_size (&msg, 4); > assert (rc == 0); > memcpy (zmq_msg_data (&msg), "ABCD", 4); > rc = zmq_send (s, &msg, 0); > assert (rc == 0); > rc = zmq_msg_close (&msg); > assert (rc == 0); > > you should be able to use standard POSIX syntax: > > nbytes = zmq_send (s, "ABCD", 4, 0); > assert (nbytes == 4); > > Existing zero-copy functionality will be retained though, presumably as > zmq_sendmsg() and zmq_recvmsg(). > > 2. Review the types of socket options (getsockopt/setsockopt). The types > are almost completely arbitrary now. Choose sane types instead. > > 3. Change zmq_poll's timeout value unit from microseconds to > milliseconds to make it coherent with POSIX poll. A side note being that > implementing the poll with sub-millisecond precision is very hard, not > really reliable and the resulting performance is poor. > > 4. Join ZMQ_RECOVERY_IVL and ZMQ_RECOVERY_IVL_MSEC into a single option. > The two options exist only for backward compatibility reasons. We can > remove one of them now. > > 5. Remove ZMQ_MCAST_LOOP option. Disable multicast loopback entirely. As > am I told, it's basicallt a hack and it's slow and lossy. It makes sense > to disable this option so that users use ipc transport instead, which > behaves more decently. > > 6. Remove deprecated ZMQ_UPSTREAM, ZMQ_DOWNSTREAM constants. These were > renamed to PULL and PUSH a long time ago. > > 7. Devices should be moved out of ØMQ core. The devices are pretty > independent from the core. Moreover, different fancy devices looks like > a natural way to deliver value on top of 0MQ. Removing the "official > devices" from the core seems to be the obvious step towards opening this > market to more development and competition. > > 8. On-disk swap should be made a device rather than an internal feature > of ØMQ sockets. Persistence is a hard problem and should be solved > independently of 0MQ core which is basically a networking library. > > 9. C++ binding should be removed from the core. All the other language > bindings are separate projects. There's no reason to treat C++ in a > special way. > > 10. I would like to remove ZMQ_PAIR pattern altogether, however, Pieter > uses it in the guide, so he proposes to instead limit it to inproc > transport which is the only use case there. Please, if you are using > PAIR, whether over inproc or tcp or whatever, scream now!
I use PAIR quite a bit, because many of my small cases really are symmetric a<=>b connections (not REQ/REP pattern). Frankly, I can easily use XREQ for both sides if PAIR is gone, and it works as long as additional connections don't happen, but if they do things will go wrong. I'd rather have the error raised by PAIR than weird message loss that would result from XREQ. What would be the recommended socket type(s) for a symmetric pair of sockets with flexible send/recv pattern if PAIR is removed? -MinRK > > For those interested in 0MQ wire format, there are two proposed changes > at the moment: > > 11. Make the TCP connection header extensible. Right now it conveys only > end point identity. It should be able to contain arbitrary information. > The goal is make the connection initiation future-proof. The goal is not > to specify hard-wired set of properties to communicate on the connection > initiation, rather it's to allow adding new property without breaking > the backward compatibility. > > 12. There's a single message flag now. 'MORE' indicates that there are > more message parts for this message to follow. This flag should be > replaced by pair of flags, namely BEGIN and END flag. Explicitly marking > beginning of message allows late joiners to the pub/sub feed to start > receiving messages faster. Also, it helps with manual wire format > dissection (via tcp dump or somesuch). > > Please, do discuss these proposals, as we'll have to stick with the > outcome for a long time! > > Martin > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
