On Sat, 28 May 2011 07:54:56 +0200, Jonas Sicking <jo...@sicking.cc> wrote:
On Fri, May 27, 2011 at 5:47 PM, Adrian Bateman <adria...@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
This argues for making the subprotocols argument an object in the API. I
think that would be a good change, and I agree that open() would be added
complexity with little benefit.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12816
--
Simon Pieters
Opera Software
