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
