W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

Re: [websockets] Constructor vs. open()

From: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 27 May 2011 22:54:56 -0700
Message-ID: <BANLkTi=sBJ-eoth3LBACL0Y1QLC0gOeyUg@mail.gmail.com>
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 GMT

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