[whatwg] Why deflate-stream is required to be enabled by the WebSocket API?

[John Tamplin]

On Wed, Jul 20, 2011 at 6:54 PM, Adam Barth <w3c at adambarth.com> wrote:

> Isn't the obvious solution to both problems to apply compression before
> masking?
>

Yes.  However, that is not what deflate-stream does.  There has been a
proposal for deflate-frame which would do exactly that, but it has not been
accepted as of yet and there seems to be some resistance to including it in
the base spec at the expense of further delaying it.

deflate-stream was created as a "better than nothing" compression nobody
objected to that served as an example in the spec of an extension.  Since
then, largely due to your work, masking client->server traffic was added
which reduced the value of deflate-stream in that direction and also
requiring the extension be handled outside the normal framing.

The fact that the WS API would mandate deflate-stream and not allowing
browser to support other extensions would in fact prevent the deployment of
deflate-frame later, or for that matter any other improvements.  I could
hope that browsers would ignore that requirement and support other
extensions, but then the spec isn't reflecting reality.

As a further example, if multiplexing is added later, it may well need to
have compression at a different level (otherwise mux/demux operations have
to decompress and recompress) -- mandating deflate-stream would again
complicate that scenario.

-- 
John A. Tamplin
Software Engineer (GWT), Google