W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > September 2019

Re: [webrtc-pc] Order of multiple RTCDataChannel.send calls in case of blobs (#2215)

From: guest271314 via GitHub <sysbot+gh@w3.org>
Date: Wed, 04 Sep 2019 07:41:04 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-527783114-1567582863-sysbot+gh@w3.org>
To preserve order at Firefox `async/await` and `arrayBuffer()` of `Blob` can also be used 

```
async function sendData()
{
  log("Sending data of size 4");
  channel1.send(await new Blob(['blob']));

  log("Sending data of size 8");
  channel1.send(new ArrayBuffer(8));
}
```
https://jsfiddle.net/jy4r3aqc/

See this [answer](https://stackoverflow.com/a/56419176) at [Where is Blob binary data stored?](https://stackoverflow.com/q/38239361)

> Blobs represent a bunch of data that could live anywhere. The [File API specification](https://www.w3.org/TR/FileAPI/) intentionally does not offer any synchronous way of reading a Blob's contents.

Given there is an expectation of order relevant to WebRTC specification the capability to set the input/output order of `MediaStreamTrack`s in a `MediaStream` (potentially recorded by `MediaRecorder` and output as a media file) should also be specified. 

Why should not order be considered important for all `MediaStream`s and data channels where the underlying source of the implemenation is WebRTC specification?

If order is important for data channel order must also be important for `MediaStreamTrack`s added to a `MediaStream`. 

At least in this case using an a single constructor or `async/await` and a single method of `Blob` can be applied to achieve the expected result rather than parsing files which have arbitrary track order set not inconsistently with the specification https://github.com/pthatcherg/web-codecs/issues/11#issuecomment-527698222.


-- 
GitHub Notification of comment by guest271314
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2215#issuecomment-527783114 using your GitHub account
Received on Wednesday, 4 September 2019 07:41:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:22:28 UTC