[nanomsg] Re: New release?
- From: Garrett D'Amore <garrett@xxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Mon, 27 Oct 2014 16:49:46 -0700
In fact, nanocat & macat both do msgpack serialization, IIRC.
These details definitely belong in the app layer above, not in nanomsg itself,
IMO. Don’t tie the protocol to a particular packing format, but keep it
agnostic, because whatever you try to choose, it will be wrong (for some
applications).
- Garrett
> On Oct 27, 2014, at 3:40 PM, Drew Crawford <drew@xxxxxxxxxxxxxxxxxx> wrote:
>
>> 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
>> <mailto: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
>>> <mailto:dirkjan@xxxxxxxxxx>> wrote:
>>>
>>> On Mon, Oct 27, 2014 at 5:18 PM, Jack Dunaway <jack@xxxxxxxxxxxxxxxx
>>> <mailto: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
>>>> <//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: