Hi all,
I've just committed a patch that adds extensibility mechanism to 0MQ
wire format ('flags' byte).
It means that old 0MQ applications won't be able to speak to new 0MQ
applications unless you recompile them.
Martin
___
zeromq-dev mailing list
z
sust...@250bpm.com said:
> I've just committed a patch that adds extensibility mechanism to 0MQ
> wire format ('flags' byte).
>
> It means that old 0MQ applications won't be able to speak to new 0MQ
> applications unless you recompile them.
To elaborate on Martin's english compression somewhat,
For what it's worth, both old and new formats are documented here:
http://rfc.zeromq.org/
Martin, could you check that 2:spb is correctly documented there?
-Pieter
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/l
Pieter Hintjens wrote:
> For what it's worth, both old and new formats are documented here:
> http://rfc.zeromq.org/
>
> Martin, could you check that 2:spb is correctly documented there?
It's more or less correct. However, if you want a more detailed
description of the format, you can copy the t
Hi,
Why don't we add a protocol version? zmq servers can check the version
and drop messages they don't support.
Any thoughts on supporting different wire protocols? Idea is to talk
to non-zmq servers, ie. redis/memcached. We don't have API hooks for
this, but we can have pluggable encoder, decod
Hi Dhammika,
> Why don't we add a protocol version? zmq servers can check the version
> and drop messages they don't support.
Rather than negotiating the version, implementations can simply drop the
messages that have unrecognised flags set IMO.
> Any thoughts on supporting different wire pro
