Martin, Could you post this on the wiki, so we have a point of reference?
Thanks Pieter On Mon, Mar 21, 2011 at 4:57 PM, 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! > > 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
