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

RE: [websockets] Binary support changes

From: Adrian Bateman <adrianba@microsoft.com>
Date: Sat, 28 May 2011 00:47:48 +0000
To: Ian Hickson <ian@hixie.ch>, Jonas Sicking <jonas@sicking.cc>
CC: "Web Applications Working Group WG (public-webapps@w3.org)" <public-webapps@w3.org>
Message-ID: <104E6B5B6535E849970CDFBB1C5216EB432ED5DF@TK5EX14MBXC136.redmond.corp.microsoft.com>
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.

Adrian.
Received on Saturday, 28 May 2011 00:49:16 GMT

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