[WebSocket API] .binaryType

Hi All,

We've been working on finishing up our implementation of the WebSocket
API for firefox and have mostly one outstanding issue.

The problem is the .binaryType property. There are two problems that I
see with how it's currently defined.

1. It doesn't allow receiving textual messages as Blobs, only binary
messages can be stored as blobs.
2. Since the binaryType can be changed at any time, this makes
implementation somewhat complex and have slower performance.

Regarding 1:
The usecase for blobs in general would be downloading large messages
where the contents of the message won't be immediately used, but
rather stored for later use. For example a offline webmail page could
use websocket to synchronize emails and their attachments. Here the
receiving page would want to receive the attachments as Blobs to be
stored in IndexedDB or the Filesystem API. As the WebSocket API spec
is currently defined, this only works if the attachments are sent in a
binary format. So for example HTML attachments can't be sent as text.

I've never quite understood why only binary messages fulfills the
property of "being large and will only be used later".

Regarding 2:
Since .binaryType can be changed any time, you can end up in the
situation where the implementation has streamed the incoming data to
disk, and at the last second the binaryType changes from "blob" to
"arraybuffer". At this point the implementation will have to start
reading back the data from disk and stall any message events until the
data has been fully read back. However before firing the event the
implementation will have to check that .binaryType hasn't changed
again, and if it has possibly stream the data back to disk.


There are two changes that I propose in order to fix these two issues:

1. Change .binaryType to .dataAsBlob. dataAsBlob would be a boolean
which if set to true would make data be delivered as a Blob rather
than a String or ArrayBuffer. Another alternative would be have a
.nextAsBlob property. nextAsBlob would work like dataAsBlob, but is
set to false right before firing each message event (but of course
after constructing the Event object with the actual data).

2. Allow .binaryType/.dataAsBlob only during message and open events.
This would allow the implementation to for example hold incoming data
in memory until after the previous message event has been fully
dispatched. This way no unneccesary IO is done. Under normal
circumstances (where the bandwidth to the server is proportional to
todays bandwidths, and where developers try to maintain a responsive
UI) this implementation strategy will work quite well. More complex
implementation strategies can of course still be used, but in either
case the implementation doesn't have to worry about the format
changing once the previous event has been dispatched.


So far I haven't been able to get any feedback either way from other
browser developers on this issue. If no-one else is worried about this
then Firefox will simply go ahead and implement the spec as it stands
today. However I wanted to share my concerns with other
implementations first.

/ Jonas

Received on Thursday, 1 September 2011 20:13:02 UTC