Webrtc-pc: 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.