Transferable Streams

[ricea]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Transferable Streams
• Specification or proposal URL: https://streams.spec.whatwg.org/
• Caniuse.com URL (optional):
• Bugzilla URL (optional): https://bugzilla.mozilla.org/show_bug.cgi?id=1659025
• Mozillians who can provide input (optional):

Other information

Pull request: whatwg/streams#1053
TAG early review: w3ctag/design-reviews#332
Explainer: https://github.com/whatwg/streams/blob/master/transferable-streams-explainer.md
Relevant sections of the standard:

• https://streams.spec.whatwg.org/#rs-transfer
• https://streams.spec.whatwg.org/#ws-transfer
• https://streams.spec.whatwg.org/#ts-transfer
• https://streams.spec.whatwg.org/#transferrable-streams

[tschneidereit]

CC @lukewagner, as this might be relevant to some WebAssembly related uses of Streams.

[plorenz-etes]

Since #330 (insertable streams) is now marked as "worth prototyping", I think transferable streams should be, too.

In order to implement end to end encryption in audio/video calls, insertable streams are required. However, the encrypting/decrypting process should be moved to a worker ( https://developer.mozilla.org/en-US/docs/Web/API/Worker ) in order to help performance - but this can only be done if passing streams to a worker is possible, which requires transferable streams.

[martinthomson]

These are not likely to be the same thing. "Insertable streams" (ugh, that name still annoys me) is looking like it might be implemented using a worklet style of script rather than a full worker, and it applies mostly to WebRTC media streams. So there might be some sense in maximizing the similarities, it doesn't seem like those are guaranteed.

For this, the opinions of @asutherland or @annevk might be useful.

[annevk]

I have not reviewed the algorithms in detail, but this is a feature we've been supportive of ever since we talked about adding streams to the web platform. So I suggest we close this as worth prototyping.