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

Re: [websockets] Making optional extensions mandatory in the API

From: Anne van Kesteren <annevk@opera.com>
Date: Fri, 22 Jul 2011 16:48:36 +0200
To: "Takeshi Yoshino" <tyoshino@google.com>
Cc: "Greg Wilkins" <gregw@intalio.com>, "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.vy0zfau964w2qv@annevk-macbookpro.local>
On Fri, 22 Jul 2011 12:45:42 +0200, Takeshi Yoshino <tyoshino@google.com>  
wrote:
> In summary, your point seems to be that we must choose feature set that  
> is considered to be taken by majority as optimal like HTTP/gzip, and ask
> browsers to support that by specifying it the W3C spec (*). I see that.  
> It might make sense. However deflate-stream is not yet considered as the
> optimal choice in the HyBi WG and we're trying to introduce better one.  
> Even some are doubting if it's worth using deflate-stream compared to  
> identity
> stream.
>
> Requiring all browsers request (== implement) deflate-stream can be  
> asking everyone to do thrown-away work as a result. Is this acceptable?
>
> Based on W3C's stance (*) and IETF's stance, the only landing point is
> initially enforcing browsers to use identify encoding except for
> experimenting new compression, and when IETF provides new compression
> extension good enough to recommend, update the API spec to switch to  
> that.

I think like Ian I had not expected features you do no want to see  
implemented to make it into a final draft. The API can go either way. We  
could either say MUST NOT or MUST. Optional features is just not really an  
option.


-- 
Anne van Kesteren
http://annevankesteren.nl/
Received on Friday, 22 July 2011 14:49:34 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:46 GMT