binary

[juliangruber]

[15:50:41] actually I think binary mode should be the default
[15:50:55] as a "real" stream/transport/socket supports binary
[15:51:42] currently multilevel requires a binary capable stream, and i need to make an option {binary:false}, in which case it should encode buffers as base64 or anything else that behaves well
[16:12:36] juliangruber: yes, I'd be happy to merge that -

will do

[AaronO]

Any updates on this ?

I currently need this given that I'm doing nested multiplexing (mux-demux on top of another mux-demux stream) as well as transporting binary data.

Is there a decent workaround I could use in the meantime ?

Thanks

[nakosung]

+1

[juliangruber]

This is fixed!

• require('mux-demux/jsonb') works over non binary capable transports and base64-encodes binary data
• require('mux-demux/msgpack') works only over binary capable transports and is more effective

[dominictarr]

be warned though, that jsonb is base64's the data, so it expands. this is necessary when using with shoe/sockjs
because binary is not yet supported. see: sockjs/sockjs-protocol#74

[nakosung]

What about binary.js? It seems to offer better performance. 'mux-demux/binarypack' :)

1. 9. 1., 오후 9:35, Dominic Tarr [email protected] 작성:

be warned though, that jsonb is base64's the data, so it expands. this is necessary when using with shoe/sockjs
because binary is not yet supported. see: sockjs/sockjs-protocol#74

—
Reply to this email directly or view it on GitHub.

[dominictarr]

@nakosung I would certainly merge a pull request adding binary-pack encoding!

[dominictarr]

would be great to see perf difference between it and msgpack

[nakosung]

FYI, unfortunately, I'm not in a hurry with new binary.js thing for now. Maybe months later I will need 'the better performance'. Currently I'm happy with utf-8 stream for prototyping.

1. 9. 2., 오후 5:22, Dominic Tarr [email protected] 작성:

would be great to see perf difference between it and msgpack

—
Reply to this email directly or view it on GitHub.