- 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