[nanomsg] Re: ws transport
- From: Garrett D'Amore <garrett@xxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Sun, 30 Nov 2014 09:55:14 -0800
> On Nov 29, 2014, at 3:02 PM, Drew Crawford <drew@xxxxxxxxxxxxxxxxxx> wrote:
>
>> Funny thing is, I think that fork already occurred in some way. You could
>> view “nanomsg” as a philosophical fork from zeromq.
>
> Yes “you could” view it that way but it is mentioned in only in passing on
> the “why nanomsg” page: http://nanomsg.org/documentation-zeromq.html
> <http://nanomsg.org/documentation-zeromq.html>
>
> Quite simply, one can adopt a pro-C, pro-POSIX, pro-pluggable, etc., view,
> without adopting the scalability philosophy, or adopting it only weakly, as I
> do.
Oh, but if you’re going to start adding all these rich capabilities, I think
you’re going to wind up leaving the POSIX bit behind you. In fact, the POSIX
API is a convenience to facilitate adoption, I think. (I can’t argue with an
anti C++ stance, of course, but ultimately it shouldn’t matter *that* much
since ØMQ exports C apis. Unless you’re hacking the core itself, of course.)
Of course, “full POSIX compliance” is utter claptrap — instead the wording
should say “more familiar POSIX-style API”. (An application can be POSIX
conformant if it only consumes POSIX APIs. A *platform* (usually an Operating
System) can only be POSIX conformant if it exports certain APIs and semantics
(and also avoids adding other names to the namespace.) POSIX conformance for a
*library* makes no sense whatsoever. POSIX-style familiarity is different, of
course. ;-)
The pluggability of nanomsg is, quite honestly, a bit off the mark, I think. I
tried adding new protocols, but you wind up basically implementing much of the
same code. I think Martin has some new ideas here. Btw, I think I achieved a
much greater level of pluggability in my mangos implementation - some of the
protocols and transports weigh in under 200 lines of code. :-)
>
> Also worth mentioning that the alternative to scalability isn’t just
> “anti-scalability” but also something like “scalability plus” or “scalability
> lite”. Things like “scalability plus security” or “scalability plus
> sessions” or “scalability plus interop with web technologies” are positions
> between where zeromq is and where nanomsg is.
I’m not sure what you mean by scalability here. I usually mean in it a
performance/operation at scale context. But I think you’re talking more about
extensibility.
>
> In short, there are paths from nanomsg that don’t lead back to zeromq, but
> lead to some third place. I’ve been debating for some time whether there’s
> enough of a problem here that the shortest path is firing off in that
> direction. In some ways I’ve already done that, but I haven’t really
> committed to it just yet. I’m still hedging my bets.
>
I recall your prior concerns were about security. You wanted to inject a
crypto layer into the transport, IIRC. I was probably your most vocal
detractor. I’m probably coming around to your point of view, but I still
become *very* cautious when adding crypto (or security protocols) to a product.
The road is littered with the bodies of people who’ve failed badly here
because they lacked sufficient knowledge to properly design and analyze a
security protocols. WEP was a classical blunder by well-meaning yet naive
designers. (We do have tls+tcp at least in RFC and mangos, although we
haven’t got it in nanomsg itself, mostly because I haven’t found the cycles or
energy to do it — for my purpose the implementation in mangos suffices, and I
can make a plaintext<->crypto gateway as a mangos device. :-)
I will add just a little more here.
1. I’m not doing the coding for nanomsg core itself, so arguably my feelings /
opinions are probably of less value than those of others…
2. However, as the author and maintainer of the only alternate implementation
of the SP protocols, I’m *strongly* in favor of keeping the protocols
relatively simple, and easy to implement towards. Adding a bunch of
functionality that blurs the layering and creates a maintenance burden on other
implementations (or a barrier to other implementations) is something I’d be
relatively opposed to. New message packing schemes, new crypto
algorithms/protocols, etc. all raise that bar (and also may be seen as limiting
application choice, even if not actually doing that), so I’ve got some natural
resistance.
You might think that alternate implementations are not important. I contend
they are — nanomsg’s core relies upon specific asynchronous I/O APIs being
available, and frankly interacts poorly in certain contexts (go is one of them,
btw), so being able to provide more natural implementations with other design
goals (like a more familiar Go API) is useful to the health of the overall
ecosystem. And I believe an SP ecosystem is what we actually want to achieve
here, not just a single library. (And by the way, if ever the protocols were
to be accepted at IETF for RFC consideration, there would *need* to be
alternate implementations.)
- Garrett
Other related posts:
