Transferable Streams Spec

[ricea]

Saluton TAG!

I'm requesting a TAG review of transferable streams.

The streams APIs provide ubiquitous, interoperable primitives for creating, composing, and consuming streams of data. A natural thing to want to do with a stream is pass it off to a web worker. This provides a building block that is easy and natural to use for offloading work onto another thread. Once you can speak the language of streams, you can use that same language to make use of a Worker.

• Explainer¹ (minimally containing user needs and example code): https://github.com/whatwg/streams/blob/master/transferable-streams-explainer.md
• Specification URL: https://streams.spec.whatwg.org/
  Specific sections:
  • 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
• Tests: [wpt folder(s), if available]: Add tests for transferable streams web-platform-tests/wpt#24546 (not landed yet)
• Security and Privacy self-review²: https://docs.google.com/document/d/1z70irwTjE1ru2AtrejMQa9KJ36Zjhm8sTBTRB7OwFqg/view
• GitHub repo (if you prefer feedback filed there): https://github.com/whatwg/streams
• Primary contacts (and their relationship to the specification):
  • Adam Rice (ricea), [Google] Spec editor
  • Domenic Denicola (domenic), [Google], Spec editor
• Organization(s)/project(s) driving the specification: WHATWG
• Key pieces of existing multi-stakeholder review or discussion of this specification: can streams be transferred via postMessage()? whatwg/streams#276
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/5298733486964736

Further details:

• I have reviewed the TAG's API Design Principles
• Relevant time constraints or deadlines: No specific deadlines, however most users of WebRTC Insertable Streams are using transferable streams and are waiting for us to ship this.
• The group where the work on this specification is currently being done: WHATWG
• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): WHATWG
• Major unresolved issues with or opposition to this specification: Unresolved issue: when a stream is transferred twice, eg. A -> B -> C, a developer might reasonably expect that this leaves the stream in a state equivalent to A -> C. However, if the B context is terminated, the stream will error the next time an operation is performed on the stream. This behaviour is counter-intuitive, but the problem is very hard to fix. For more information, see the issue and the linked comment thread.
• This work is being funded by: Google

You should also know that...

This feature previously had an early review at #332.

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

---

[cynthia]

@ylafon and I discussed this during our "F2F".

One concern is that the overrides for the methods in readable/writeable streams could be confusing initially, but users will most likely adapt to it after some initial confusion - so not an issue that should block progress, but maybe something to think about.

Aside from that, no outstanding issues we see here, and we are happy to see this work move forward. Thanks for bringing this to our attention!

[cynthia]

Group agreed to close this. Thanks for bringing this to our attention!