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 >>> >> >> >