W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)

From: Anne van Kesteren <annevk@opera.com>
Date: Fri, 22 Jul 2011 11:54:46 +0200
To: "Greg Wilkins" <gregw@intalio.com>, "Takeshi Yoshino" <tyoshino@google.com>
Cc: "Web Applications Working Group WG (public-webapps@w3.org)" <public-webapps@w3.org>, "Maciej Stachowiak" <mjs@apple.com>, "Arthur Barstow" <art.barstow@nokia.com>, "Adrian Bateman" <adrianba@microsoft.com>, "Ian Hickson" <ian@hixie.ch>, "ifette@google.com" <ifette@google.com>, "jonas@sicking.cc" <jonas@sicking.cc>, "simonp@opera.com" <simonp@opera.com>, "Brian Raymor" <Brian.Raymor@microsoft.com>
Message-ID: <op.vy0ltka664w2qv@annevk-macbookpro.local>
On Fri, 22 Jul 2011 07:03:34 +0200, Takeshi Yoshino <tyoshino@google.com>  
> Think of these facts, the only "dominant implementation" concern I can  
> come up with for WebSocket compression is that big service provides may  
> take an aggressive policy that they require users to use only WebSocket  
> client with compression capability to reduce bandwidth. As a result  
> clients with no
> compression capability may, in effect, be kicked out of WebSocket world.
> I can understand that concern. Is this true for the HTTP world? I.e.  
> clients that send "Accept-Encoding: \r\n" cannot live?

Yes. Optional features for browsers do not work. For servers it is fine if  
they do not support compression or whatnot, but browsers pretty much need  
to align on feature set.

Anne van Kesteren
Received on Friday, 22 July 2011 09:55:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:23 UTC