Intent to Implement: Streams API: Transferable Streams
Adam Rice
Contact emails
ri...@chromium.org, yhi...@chromium.org
Explainer
https://github.com/whatwg/streams/blob/master/transferable-streams-explainer.md
Design doc/Spec
https://docs.google.com/document/d/1_KuZzg5c3pncLJPFa8SuVm23AP4tft6mzPCL5at3I9M/edit
Standards work is in progress.
No tag review as no APIs are being added; this just makes one more thing transferable, which is an already well-reviewed pattern.
Summary
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 Worker. This provides a fluent primitive for offloading work onto another thread. Transferable Streams add this capability by allowing ReadableStream, WritableStream and TransformStream objects to be passed as arguments to postMessage().
Motivation
Using the postMessage() API to handle streaming data is fully possible, however abstraction is difficult. Transferable streams make this trivial. The design permits bypassing JavaScript and other optimisations which are not possible with postMessage(). The initial implementation won’t be faster, but by mid-2019 we can expect it to be significantly more efficient.
Risks
Interoperability and Compatibility
Edge: No signals
Firefox: Public support
Safari: No signals
Web developers: Positive
Please include links where possible.
Ergonomics
This will most commonly be used with Workers or ServiceWorkers.
The API is asynchronous and designed to permit good optimisation decisions.
Activation
The feature puts together two things that developers are already using, so it will be easy to adopt.
High-fidelity polyfilling is made difficult by the need to intercept “message” events, but it’s possible to make a “good enough” polyfill to simulate the behaviour. See https://github.com/MattiasBuelens/remote-web-streams for example. Alternatively, developers could offload work onto another thread in browsers implementing transferable streams, while continuing to run it on the main thread in other browsers.
Detecting support for transferable streams is awkward. It’s necessary to postMessage a stream and see if it works.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Link to entry on the feature dashboard
https://www.chromestatus.com/feature/5298733486964736
Requesting approval to ship?
No
Philip Jägenstedt
I can imagine that supporting this would be non-trivial in some
implementations, maybe it's worth proactively seeking out their
feedback long before we get close to shipping this?
> You received this message because you are subscribed to the Google Groups "blink-dev" group.
> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAC_ixdzfSBecokVHkxVb%2BLB_Y%2BeY5Z8%2BR43FBAWt4EVSjo94Gg%40mail.gmail.com.
Adam Rice
I can imagine that supporting this would be non-trivial in some
implementations, maybe it's worth proactively seeking out their
feedback long before we get close to shipping this?
You received this message because you are subscribed to the Google Groups "blink-network-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-network-...@chromium.org.
To post to this group, send email to blink-ne...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-network-dev/CAARdPYehmwDOgo%3DxQy9mTY18ZKe60GMDAOOxSoibe8dHKShNRA%40mail.gmail.com.
Philip Jägenstedt
>>
>> I can imagine that supporting this would be non-trivial in some
>> implementations, maybe it's worth proactively seeking out their
>> feedback long before we get close to shipping this?
>
>
> Definitely. Although it's pretty non-trivial in Blink too :-)