IMHO, ZMTP adds pains where it should not. In particular, it does not enable to proxy its mechanisms. So one cannot design an architecture with untrusted nodes in the middle, unless hacking a three layers ZMTP protocol with ZMQ_STREAM.
I agree with Martin the best choice is to stay minimal, and everyone adds what one needs on top of it. In the very beginning, I did complain as you do, expecting an easy go from 0MQ to nanomsg. But nanomsg legitimate aim is to not reproduce the errors made before. So it cannot have the same API, or either a compatible one.
In my use case, I have needed a security communication through the wild. First I hacked 0MQ, adding a mechanism of my own, then the 3 ZMTP layers stack story (it works but you loose all your hair), then an independent library on top of 0MQ, and then nanomsg, because I am more confident in its design (let's read 0MQ mailing list to figure out why).
My 2 cts. Laurent. Le 21/04/2014 10:51, Doron Somech a écrit :
What is the issues with ZMTP?On Mon, Apr 21, 2014 at 11:27 AM, Laurent Alebarde <l.alebarde@xxxxxxx <mailto:l.alebarde@xxxxxxx>> wrote:Le 20/04/2014 14:27, Martin Sustrik a écrit :One of the explicit goals I've had with nanomsg was to fix the mistakes I've done in ZeroMQ, including the flaws in the protocol. - From the historical standpoint: I've devised ZMTP very early on (summer 2008 IIRC) as a simple throw-away protocol, to be replaced by something better once we understand the domain better.I have migrated to nanomsg because of ZMTP. Laurent.
