Re: [hybi] Proposed way forward for WebSockets

[John Tamplin <[e-mail]>]

On Tue, Jul 27, 2010 at 2:13 AM, Anne van Kesteren <[e-mail]> wrote:

> On Tue, 27 Jul 2010 06:56:27 +0200, Greg Wilkins <[e-mail]>
> wrote:
>
>> I would add 4: to support  the deployment of future extended versions of
>> the protocol.
>>
>> Thus having a mechanism for versions and feature negotiation is key in a
>> 1.0
>>
>
> Feature negotiation is there, by means of new headers.


If that is the intention, it would be good to state that in the protocol,
especially since an earlier version specifically outlawed additional headers
and there is confusion over the interpretation of the current version's
stance on additional headers.  Additionally, I think there needs to be room
for expansion of frame types (which is currently there).

Breaking backwards compatibility so that you need to support two or more
> versions forever seems like a bad idea.


The alternative is simply breaking old implementations if there is no
versioning and you find you need to make incompatible changes.  Including
versioning now is small insurance against such a requirement.

I think it is worth considering keep-alives for the initial version -- the
alternative, if implemented at the application level, is a mess of
incompatible implementations that can't be pooled or limited by the browser
(such as on a phone that needs to curtail network activity to conserve
battery) without interfering with legitimate traffic, since the browser
can't identify it.

Another one that I think is impractical to expect JS implementations of is
compression.  What would demonstrate sufficient need for compression support
if it is not reasonable to expect the compression to be implemented in JS -
would demonstrations of improvement of real-world performance of real-world
apps across a compressed WebSocket be sufficient?

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