Hi Martin,
[email protected] said:
> 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.
Sounds good.
> 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*.
I would like to emphasise this point. We can now reflect on what we know
from our users, at look at getting the long-term API *right*. So people,
please contribute to this discussion!
>
> 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().
Pieter, you asked for a zmq_recv() example. It's analogous to POSIX recv():
char *buffer[1000];
rc = zmq_recv (s, buffer, 1000, 0);
with the obvious caveat that you will get something like EMSGSIZE back if
you gave a 1000 byte buffer, but the next-to-be-received message is too
large to be held in that buffer. I.e. no partial recv()s.
> 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.
The point is to get closer to POSIX, even if we don't actually implement
sub-millisecond precision. So we can just document that the implementation
has a precision of X.
>
> 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!
The alternative I presume is to fix PAIR sockets? I.e. implement
auto-reconnect and all the other missing bits?
>
> 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!
I would like to add at least one feature discussed before (AFAIK the IPython
people are using this heavily and are emulating it with a hack, I've also
done this for clients), namely to allow "bind to random port".
This requires an API change (getting the resulting endpoint back from the
bind call), I'm not yet sure what that API should look like but I'll make
the note here and on the Wiki page so that we don't forget about it.
-mato
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
