[nanomsg] Re: New release?

  • From: Dirkjan Ochtman <dirkjan@xxxxxxxxxx>
  • To: nanomsg <nanomsg@xxxxxxxxxxxxx>
  • Date: Mon, 27 Oct 2014 18:25:07 +0100

On Mon, Oct 27, 2014 at 5:18 PM, Jack Dunaway <jack@xxxxxxxxxxxxxxxx> wrote:
> One example -- close handshakes and failed connections as per RFC 6455
> compete with nanomsg's attempt to transparently re-establish dropped
> connections and resend failed deliveries. Another consideration is
> wire-level packing of SP metadata. This suggests the desire for a good
> JavaScript implementation of the scalability protocols, and perhaps even
> considering non-binary packing like JSON or MessagePack to give a natural,
> idiomatic feeling the developers this transport intends to serve.
>
> Considerations like this add opinionated-ness to the otherwise unopinionated
> nanomsg core library, and I'm reticent and ambivalent to be the one
> suggesting a JSON (or msgpack or ...) parser as a dependency of core
> nanomsg. (Already, the WebSocket protocol has necessitated creating a
> single-purpose SHA-1 hasher, Base64 encoder, and UTF-8 validator; I say
> single-purpose, because these functions are currently private functions
> within the WS transport namespace, were easy enough to implement without
> relying on another library or license, and are not necessarily intended for
> use by the nanomsg library user). Might this suggest pluggable wire
> protocols as a fundamental new feature?? (This could also solve the
> NN_PIPE_PARSED conundrum:
> //www.freelists.org/post/nanomsg/header-behavior-for-ipc-vs-inproc)

Great points, Jack.

I wrote a ZeroMQ-to-WebSockets proxy for my previous job, and I feel
like opening up the browser to nanomsg protocols is great and opens up
a pretty big set of new use cases, but you're right to be concerned
about the added complexity.

On the other hand, I think binary packing should be fine these days,
as I think modern JavaScript has some good features to deal with
binary data (I'm thinking of mostly of Typed Arrays). I'd be happy to
play with some JavaScript client code once the WS stuff is available.

I think pluggable transports would be great, but it's maybe a bit
early for that?

Cheers,

Dirkjan

Other related posts: