data channel default binaryType value is 'blob'

[youennf]

The default binaryType value is 'blob' in the spec.
Firefox implements it but Chrome and Safari uses 'arraybuffer'.
'arraybuffer' might be more convenient for web developers.
It could be promoted to the default value.

[lgrahl]

Although I generally find ArrayBuffer more useful, I'm not sure it is a good idea to do this late.

What do you think, @jesup?

[youennf]

My biggest concern is that we would no longer be aligned with WebSocket.binaryType default value.

[jesup]

The point of the overall design for the JS interface was to largely ducktype to WebSockets, so (other than setup code) you can substitute a DataChannel for a WebSocket.
Two issues: any code that assumes the default as specified for the last ~6 years might break. (This is mitigated by Chrome and now Safari not following the spec, requiring any user to deal with that.) The other is that it requires an extra step when substituting for a WebSocket.
I don't know what's still holding up resolving https://bugs.chromium.org/p/webrtc/issues/detail?id=2276 to get blob support in Chrome; bug was filed in 2013 and was blocked waiting on ndata. (Because the WG decided to reverse course and drop the original in-browser chunking in favor of ndata, which was "going to be available soon".... instead of implementing the original spec and then using ndata if and when it was available)
If the DataChannel default changes, any user leveraging the ducktype aspect (at least once issue 2276 is resolved) will need to add a binaryType = 'blob' line. Which is not a big bar, but just what would be required.

[jan-ivar]

Good points raised. I reverse my earlier position. Firefox already implements the spec correctly, so I now think we should keep the spec as is, and have Chrome fix it.

[youennf]

Closing the issue with no action then.

[annevk]

I'd like the WG to revisit this. With Chromium not supporting this feature it seems they effectively default to "arraybuffer". WebKit has done so since WebRTC support was added as well.

It seems highly unlikely Chromium and WebKit can transition away from that default to "blob" and match Gecko.

[lgrahl]

It seems highly unlikely Chromium and WebKit can transition away from that default to "blob" and match Gecko.

Why is that? If one wants support in Firefox, one has to explicitly set it anyways which I'm assuminghoping is the majority, so would the reverse case be any different?

That being said, my position hasn't changed since 2019. Everyone uses 'arraybuffer' and using RTCDataChannel interchangeably with WebSocket has not been possible since a decade now, not only because of binaryType but also because of things like the maximum message size limitation, etc.

[jan-ivar]

If one wants support in Firefox, one has to explicitly set it anyways ...

Good point!

... using RTCDataChannel interchangeably with WebSocket has not been possible since a decade now, not only because of binaryType but also because of things like the maximum message size limitation, etc.

Why is that? If I read it right it seems possible to negotiate ∞ using max-message-size 0 in SDP.

[lgrahl]

Why is that? If I read it right it seems possible to negotiate ∞ using max-message-size 0 in SDP.

Exactly my point. WebSocket and RTCDataChannel behave differently depending on configuration, so they can't be used interchangeably (at least not beyond very simple use cases). If you ever jiggle with some more data, they behave vastly different from an API perspective (flow control / buffering, .send behaviour with high buffer pressure; for the record, the API experience of RTCDataChannel is superior to WebSocket).

[annevk]

Typically in situations like this the decision is made to side with the majority of implementers as that is likely to upset the least amount of web content. With implementers willing the WG can certainly decide to do something differently, but it's been many years now and not much happened.

[alvestrand]

It is possible in SDP to ask for infinite message size.
However, no WebRTC engine that doesn't implement 'blob' will be able to accept that offer; it will always negotiate down to the largest size that it can comfortably accomodate in an ArrayBuffer.

(FWIW, the limiting factor is the need to allocate a reassembly buffer, since all the pieces of the ArrayBuffer have to be assembled before giving it to the user in a single onmessage event.)

(Parenthesis 2: If we really wanted to support infinite sizes, we should support an interface of stream, not blob - supporting blob means that instead of hitting the ceiling on the size of reassembly buffer, which occurs pretty frequently, we hit the ceiling on amount of RAM available, or, with disk-buffered blobs, amount of disk available. Those things will occur more rarely, and the code paths handling them will therefore be less tested.)

[youennf]

The main goal is to get interop here. This seems to be more beneficial than WebSocket duck typing.

Websites that do not set binaryType probably expect arrayBuffer and not blob in their vast majority (especially since Chromium is throwing when setting binaryType IIRC).
It seems therefore easier to transition implementations from blob to arrayBuffer than the reverse.

We could try to look at some websites if that helps.

@alvestrand, is there a plan for Chromium to implement blob support?

[fippo]

See https://bugs.chromium.org/p/webrtc/issues/detail?id=2276 -- filed ten years ago (as of last week)

[jesup]

As much as it pains me as the person who wrote most of the spec, 10 years of foot dragging has made this largely a moot point. The original design was quite reasonable and made sense at the time, especially since we envisioned being able to have applications based on WebSocket be easy to transition to DataChannels. WebTransport (once Safari supports it...) is a better replacement for WebSockets, though it is not API-compatible with WebSockets or DataChannels, and like WebSockets it's server-client only. DataChannels can be server-client, or peer-2-peer, so it provides important abilities the other 2 don't.

It probably makes sense to change the default at this point. It is too bad Chrome didn't at least require a type of arraybuffer to be set instead of implementing a default different than the spec, but again, that's history now.

If effort is going to be expended now to improve the API, it would be find ways to layer Streams on top of DataChannels. They weren't ready when this was designed over a decade ago.

[henbos]

Let's change the defualt?

[dontcallmedom-bot]

This issue had an associated resolution in WebRTC December 5 2023 meeting – 05 December 2023 (Issue #2170 Data channel default binaryType value is 'blob'):

RESOLUTION: change the default for binaryType to arraybuffer

[alvestrand]

Default type changed to "arrayBuffer" by PR #2913