[nanomsg] Re: New release?
- From: Drew Crawford <drew@xxxxxxxxxxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Mon, 27 Oct 2014 17:40:14 -0500
> 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.
For whatever it’s worth, I also face this issue in my fork. However I have
some properties that make a solution more straightforward:
The headers themselves, are just fixed-width fields
The message body, however is variable-length and contains complex data
In this case I can handle the serialization/deserialization outside of nanomsg
entirely. So the application programmer talks to a high-level layer, that
incorporates a system like json/msgpack, and that layer passes the
preserialized data to nanomsg.
Based on that experience, I would probably argue against selecting a
JSON/msgpack/etc. for inclusion in core. The reasoning is, there are a lot of
them, (and a lot of implementations), they are complicated, and I haven’t
really met any implementation that I like. Some cases dictate the use of
certain ones. It’s a mess.
> On Oct 27, 2014, at 12:53 PM, Garrett D'Amore <garrett@xxxxxxxxxx> wrote:
>
> 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:
