[zeromq-dev] Topics for ZMTP 3.0

[Pieter Hintjens]

On Mon, Jun 10, 2013 at 6:41 PM, Ciprian Dorin Craciun
<ciprian.craciun at gmail.com> wrote:

>     I don't think it's a good idea to have n ZMTP-cloned protocols...
> In the long term I would prefer a single less than ideal protocol,
> than a thousand "perfect" ones. :)

Fork/merge can work with protocols just as with code; the point is you
can copy the spec and make changes and publish those, and we can merge
the ones that work back. It reduces the need for upfront agreement.

Identities... if we take the current semantics, the identity is two things;

* an internal "handle" that ROUTER gives to calling apps to resend
messages back to their origins
* a way to force this handle to a predictable value, typically a uuid

The first case allows request-reply chains. There is no reason to ask
the client to invent an identity, and good arguments _against_ doing
this (it forces clients to use uuids which makes envelopes larger for
zero benefit, and creates costs for implementors (uuid library
dependencies)).

>     As such I'm only saying that by making the identity mandatory (at
> least in a couple of sockets, or even in the others as seen from the
> second example) can only make the protocol more robust.

The router's use of identities is an API-level abstraction and is only
available as metadata _at all_ to allow applications to force their
semantics onto it. It's not a protocol concept in any way.

Now we could redefine identity to becoming a protocol concept, as it
was in 2.x and earlier, where it defined the persistence of messages
held on servers. But that entire concept was taken out, for I think
good reasons.

-Pieter