[nanomsg] Re: New release?
- From: Garrett D'Amore <garrett@xxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Mon, 27 Oct 2014 10:53:02 -0700
Folks,
It would be almost trivial to just write a web sockets *proxy*, from the server
side. mangos could fill this role easily. The necessarily stuff for WS
transport are all well handled by Go.
The “value” of a websocket transport is, as you note, really dependent upon a
JavaScript implementation. (Well mostly dependent upon…)
TBH, I’m having a hard time seeing much use for this — I think a more natural
architecture is to develop applications that speak REST or something like it,
and have middleware that “translates” between nanomsg and REST. (Put another
way, I see most of the value of nanomsg and also zeromq in back end plumbing,
with little real use for it in facilitating communications with individual
clients.)
That said, I’m sure others have use cases for it. I sure as heck wouldn’t want
to be the one to try to make nanomsg in a browser-hosted Javascript library
though!
- Garrett
> On Oct 27, 2014, at 10:25 AM, Dirkjan Ochtman <dirkjan@xxxxxxxxxx> wrote:
>
> 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:
