Re: [hybi] preliminary WebSockets compression experiments

[Greg Wilkins <[e-mail]>]

Mike,

some slightly off topic thinking out loud on my idea that websockets
should be able to eventually replace the framing layer of SPDY....

The problem that SPDY poses for efficient compression implemented in the
framing layer is that it's frames may contain both headers and
a content body.

The headers are very compressible, but SPDY will probably have
already compressed them. The content body may be very compressible
(eg HTML) or not (eg JPG).

So if we were to run SPDY over websocket, then it would be unlikely
that the compression mechanism in websocket would be used, as SPDY
will have already compressed what is compressible.   It strikes me
as somewhat duplicated/wasted effort to have compression in both
layers.

Ideally websockets should be able to provide framing compression
sufficient so that SPDY (or any new application layer) would not
be required to have it's own compression mechanisms.

For SPDY, the problem of using framing compression is that the
decision to compress the headers and/or the body is separate.
So perhaps the frame batch concept in BWTP might be useful
after all - so that a HTTP message could be a batch of a
two frames, one (normally compressed) containing the headers
and another (optionally compressed) containing the body.

Note also that compression efficiency means that the current
1 header field per frame approach in the latest BWTP draft
is a non starter.



cheers