New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compression support with "deflate-frame" protocol extension #16
Comments
I didn't have plans to implement this. Not that I'm against it but it's far from being top of my to-do list. Would you like to have a go at implementing it? |
I'm not going to implement this; I don't have the time or the inclination and this extension has been superseded by |
Do you plan to support |
There's a branch where I began working on it but it looked like quite a lot of work and I'm not sure about the design. It's not high up my todo list. |
Part of the problem is that I don't know much about DEFLATE and I couldn't get Node's |
I'll have a stab at it in the weekend. |
@zzattack If you do look into this, you should be working on https://github.com/faye/websocket-driver-node, not this repo. I'd be interested in whether you think it's easier to implement on If possible, I don't think this should even be in This design is even more important in the Ruby version, where From my initial look at the spec it seems like an extension API would need to be capable of the following:
You should consider the design philosophy behind If you have any questions about the existing architecture, please ask. |
I'm also looking into implementing permessage-deflate sometime soonish. Is your opinion still the same that the right way to do this is via a separate extension module? One thing that's notable about it is that since the compress/decompress step is async, there'll need to be an extra buffering queue in both in-bound and out-bound directions to ensure that messages are emitted/written in the right order. Perhaps this is easier on the stream-parser branch; eg, you could just asynchronously not call the next |
@glasser It doesn't necessary need to be a separate npm module, but we should architect things so that nothing about permessage-deflate per se is encoded in the core driver. This will help to drive out an API design for extensions in general. That's a good point about the async compression API for zlib. The biggest stumbling block for me when I tried to implement this is that I couldn't figure out how to reproduce the examples in the spec using the Node zlib API (I'm not v familiar with how zlib works). I don't know which branch it would be easier to implement this on, my advice would be to try both and see what you find out. |
Great. I guess part of my question is, is stream parser itself finished enough that basing work on it won't introduce other issues? |
@glasser I'm not sure I'd call it 'finished', I original made it entirely to support doing extensions, but then I didn't get round to doing permessage-deflate. My hunch is you're correct about the async argument, but you would need to rebase the branch on top of master since a lot has changed since I forked. |
Hello.
WebSockets have protocol extension "deflate-frame" for per frame data compression [1].
Webkit and Chrome already support it (see [2] and Chrome sends request header "Sec-WebSocket-Extensions: x-webkit-deflate-frame").
Do you have plans to implement compression in WebSockets?
[1] http://tools.ietf.org/id/draft-tyoshino-hybi-websocket-perframe-deflate-05.txt
[2] http://www.ietf.org/mail-archive/web/hybi/current/msg09463.html
The text was updated successfully, but these errors were encountered: