- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 27 May 2011 22:54:56 -0700
- To: Adrian Bateman <adrianba@microsoft.com>
- Cc: "Web Applications Working Group WG (public-webapps@w3.org)" <public-webapps@w3.org>
On Fri, May 27, 2011 at 5:47 PM, Adrian Bateman <adrianba@microsoft.com> wrote: > As I proposed in March [1], we think it makes sense to separate the WebSocket constructor from the operation to initiate the network operation. We proposed a separate open() method similar to XHR. This allows a WebSocket object to be constructed and initialised prior to communication. We think this makes the design more future-proof because otherwise and new information required prior to establishing the connection will need to be added to the constructor arguments. > > I'm interested to know how other implementers feel about this proposal. I do really appreciate the future-proof argument. However, adding arguments to the constructor can take us pretty far. Something like: p = { protocol: "foo", timeout: 60, priority: 5, encryption: { algo: "AES256", key: x } }; w = new WebSocket(url, p) is pretty comparable to: w= new WebSocket(); w.protocol = "foo"; w.timeout = 60; w.priority = 5; w.encyption.algo = "AES256"; w.encyption.key = x; w.open(url); The main argument against a .open function that I have is that it forces us to deal with what happens if you call .open multiple times. It's kind of a pain that XMLHttpRequest allows multiple calls to open as it adds a lot of implementation complexity for very little user benefit. / Jonas
Received on Saturday, 28 May 2011 05:55:53 UTC