- 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>
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 UTC