This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Microsoft proposes that: 1. As proposed in 12816 [1] - Make second argument in constructor an object for future extensibility - a property bag is added to the constructor. 2. The property bag initially includes protocols and binaryType. 3. The binaryType is immutable after the connection is established. The binaryType attribute is read only. As discussed in Bug 12102 [2] -WebSocket protocol update time if there is a significant need to allow binaryType to be changed after a connection is established, then it can be enabled in the next version. Currently, it is introducing complexity and potential performance impacts into the implementation without clear scenarios. There is also a mitigation of using ArrayBuffer<->Blob conversion routines. [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=12816 [2] http://www.w3.org/Bugs/Public/show_bug.cgi?id=12102#c40
I don't think we should make this change. Consider a socket connection used by a website like gmail. It uses a websocket connection to keep emails synchronized. Whenever an email with large attachments are synchronized, you'd want to get those attachments in the form of blobs so that they can be stored in IndexedDB or the Filesystem API without needlessly keeping them in memory. However if metadata about emails are sent in binary form (labels set on the email. Thread it belongs to. Date it was sent, etc) you'd want that in ArrayBuffer form so that it can be quickly parsed and stored in the appropriate data structures.
On the topic of implementation complexity, it seems to me that the main source of complexity is dealing with the situation when .binaryType is set to "blob" and then 95% through downloading a large binary message the page sets .binaryType to "arraybuffer". In this case the implementation has likely streamed the binary data to disk in preparation for returning a blob which is backed by a OS file-system file. The implementation is now forced to read that data into memory before firing the next "message" event. The other way around is much easier. If the page suddenly changes from .binaryType="arraybuffer" to .binaryType="blob", this isn't much different from simply receiving data. I.e. the implementation can call whatever "datareceived" function it calls whenever receiving data from the network and pass in the arraybuffer. So one option would be to change .binaryType to .nextBinaryIsBlob and only allow setting that to |true|. The property would reset to false every time right before firing the "message" event.
Some of the complexity comes from managing a buffer that might be a Blob or might be an ArrayBuffer and needing to deal with changing how it will end up after you've started receiving the message. This requires careful design to avoid unnecessary memory copies depending upon the implementation of these types. I don't think this is required elsewhere in the platform so it imposes new requirements on these types.
Comment 1 is correct. Note that the spec does handle the blob->arraybuffer case by allowing UAs to delay events accordingly. Having a boolean to control whether the next packet is blob or not doesn't really make sense for two reasons: First, the default has to be blob to avoid big binary packets from taking memory up by default. That is, blob is the better default. Second, it wouldn't help the problem. You don't know what the next packet will be until you handle the message for the previous one, by which time the UA has almost certainly already started receiving the next packet.