Re: [websockets] Constructor vs. open()

On Sat, 28 May 2011 07:54:56 +0200, Jonas Sicking <jonas@sicking.cc> wrote:

> 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

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

Received on Monday, 30 May 2011 07:22:36 UTC