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

Re: [websockets] Getting WebSockets API to Last Call

From: Ian Hickson <ian@hixie.ch>
Date: Fri, 8 Jul 2011 20:20:57 +0000 (UTC)
To: Jonas Sicking <jonas@sicking.cc>
cc: Adrian Bateman <adrianba@microsoft.com>, "Web Applications Working Group WG (public-webapps@w3.org)" <public-webapps@w3.org>, "ifette@google.com" <ifette@google.com>, "simonp@opera.com" <simonp@opera.com>, "art.barstow@nokia.com" <art.barstow@nokia.com>, Brian Raymor <Brian.Raymor@microsoft.com>
Message-ID: <Pine.LNX.4.64.1107082014150.20871@ps20323.dreamhostps.com>
On Thu, 7 Jul 2011, Jonas Sicking wrote:
> > 12816 - Make second argument in constructor an object for future extensibility
> 
> I'd like to see this change made too.
> 
> So far there's been two counter proposals in the bug for how to deal
> with future extensions (which I strongly suspect we'll end up having
> to do in the future):
> 1. Wait to open the connection until returning to the event loop which
> delays starting the already slow network handshake. This is especially
> a problem in Web Workers where returning to the event loop can take a
> very long time.
> 2. Make the second argument either be a string, a array of strings, or
> a object. This is messy both from a user perspective and from an
> implementation perspective.

This really seems to me like a premature optimisation. We shouldn't be 
fixing problems we don't already have, _especially_ if doing so 
complicates the platform (as it does here).

There are many ways we can extend the feature in the future. Named 
constructors, overloaded constructors as you suggest, designing features 
so they don't need to be set before the handshake (binaryType being an 
example of this), designing the features so that authors don't need to be 
involved at all, etc.

For example, we don't need to put a timeout feature into the constructor, 
since that's not needed before the handshake is started. We don't need to 
put priority information into the handshake, since we would likely want to 
support changing the priority setting during the lifetime of the object, 
or even on a post-by-post basis. Another feature that was suggested is 
encryption, and we already support that using TLS in a way that doesn't 
require author to explicitly set an algorithm, which is in fact likely 
better from a security perspective.

I'm not at all convinced that we are actually going to need to extend the 
constructor at all, nor that if we ever actually have to extend the 
constructor that doing so will be problematic.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 8 July 2011 20:21:23 GMT

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