- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 1 Sep 2011 13:12:05 -0700
- To: Webapps WG <public-webapps@w3.org>
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