Re: [hybi] preliminary WebSockets compression experiments

[John Tamplin <[e-mail]>]

On Fri, Apr 23, 2010 at 6:23 PM, Roberto Peon <[e-mail]> wrote:

> If compression is optional and/or negotiated, it is likely that it will
> either not be implemented, or it will be turned off by various end-user
> devices that wish to inflate benchmark numbers.
>

How would turning off compression inflate benchmark numbers?  If compression
is a win, then it should make the benchmarks worse to disable it.


> SPDY requires compression support over the headers of certain control
> frames. To date, we've not seen a case where this has resulted in a larger
> request than raw, and it does provide for at least the availability of the
> gzip functionality at the endpoint.
>
> For Websockets, if we use gzip, the decision to do so should be made
> *solely* by the sender of that data. There should probably be no
> negotiation, else we'll end up with liars and cheats again.
>

I guess I am just missing the point here.  Say I have a JS client talking to
some backend, and I want to exchange data between them.  Just like I don't
care about the underlying transport, whether a VPN or other tunnel is
involved, or how the name is resolved, I don't care how my data gets to the
other end.  When I hand a frame to the browser, it seems reasonable for it
to send it to the server the best way it sees fit (subject to the agreement
with the server) -- if compressing the data is better than not compressing
it, it should compress it.  The server should then take the data that was
received and convert it back to the form the client code provided, by
decompressing if necessary.

As a programmer who is just sending data back and forth, I would prefer not
to have to worry about it when writing my client/server code -- my server
receives a message and interprets it, and if it happened to be
compressed/decompressed along the way that's fine.  It is no different than
writing a CGI program generating HTML -- let the web server do the
compression if the client supports it.

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