WebSocket feedback

On Sat, 28 May 2011, Adrian Bateman wrote:
> On Friday, May 27, 2011 4:23 PM, Jonas Sicking wrote:
> > However, I think there might be another solution to this whole 
> > situation. There really is no reason that only binary data can be 
> > received as a Blob. Getting data as a Blob is useful any time you're 
> > dealing with a large chunk of data where you're not immediately going 
> > to process all (or even any) of the data. Hence it would make sense to 
> > allow also text data to be received in the form of a Blob.
> > 
> > So maybe a better solution is to simply add a boolean flag which 
> > indicate if data should be received in a "plain" format (strings for 
> > textual data, ArrayBuffer for binary), or as a Blob (which would have 
> > its .type set to "text/plain;charset=utf8" or "" depending on if it's 
> > textual or binary).
> 
> I don't really like this idea. I don't want to have to change the way I 
> read text messages just because I want binary data as a Blob. One of the 
> scenarios are planning for is a text message that contains meta data 
> about subsequent binary messages that will be treated as Blobs. Your 
> proposal would require extra complexity to read text from a Blob or 
> switch back and forth.

Agreed.


On Sat, 28 May 2011, Adrian Bateman wrote:
> On Friday, May 27, 2011 4:30 PM, Ian Hickson wrote:
> > On Fri, 27 May 2011, Jonas Sicking wrote:
> > > For example, what is an implementation supposed
> > > to do if a page does:
> > >
> > > ws.binaryType = otherwindow.ArrayBuffer
> > >
> > > or
> > >
> > > otherwindow.useThis(ws);
> > > with other window containing
> > > function useThis(ws) {
> > >   ws.binaryType = Blob;
> > > }
> > 
> > The spec actually defines this (it throws unless it's the same 
> > Window's as the WebSocket object's, currently).
> > 
> > What I would really like to use is an actual type type, but JS doesn't 
> > have those.
> > 
> > > Additionally, how will webpage code check if a websocket connection 
> > > is currently set to using blobs or arraybuffers if it needs to deal 
> > > with the case that the connection is potentially coming from another 
> > > global?
> > 
> > Currently, it needs to use the source global's interface objects.
> 
> This seems to add unnecessary complexity both to web developers needing 
> to keep track of the source global and to the implementation's type 
> system where we have to go through additional hurdles to get back to the 
> objects in another context. It might look pretty to use the interface 
> object but a string is just simpler and not entirely unfamiliar to web 
> developers. For example, canvas getContext is somewhat similar.

Fair enough. I've changed it to be more like responseType.


On Sat, 28 May 2011, Adrian Bateman 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.

Given the trouble open() has given us in XHR, this seems like a bad idea.


> This allows a WebSocket object to be constructed and initialised prior 
> to communication.

Why would you want to do that?


> 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.

We can easily overload the constructor, or delay the connection to the 
next time the event loop spins, allowing any additional needed information 
to be provided after the constructor has been called.


On Mon, 30 May 2011, Simon Pieters wrote:
> 
> This argues for making the subprotocols argument an object in the API. I 
> think that would be a good change

I don't understand what problem this solves. Can you elaborate?


On Sat, 28 May 2011, Adrian Bateman wrote:
>
> Should reasonArg be a DOMString to match the argument in close()?

Fixed.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 31 May 2011 20:04:13 UTC