Intent to Ship: ReadableStream's pipeTo() and pipeThrough() methods
Domenic Denicola
Contact emails
ri...@chromium.org, tyos...@chromium.org, dom...@chromium.org
Spec
https://streams.spec.whatwg.org/#rs-pipe-to
https://streams.spec.whatwg.org/#rs-pipe-through
TAG review: https://github.com/w3ctag/spec-reviews/issues/164
Summary
ReadableStream's pipeTo() is the standard way to compose Streams. It reads data from the underlying source and writes it to a WritableStream while respecting backpressure. It is designed to permit optimisations when connecting platform streams by direct access to the underlying data sources.
pipeThrough() is a simple wrapper around pipeTo() that provides elegant syntax for chaining multiple streams. Example:
httpResponseBody
.pipeThrough(transformation)
.pipeTo(destination);
Here transformation is a transform stream that converts data to another format.
Link to “Intent to Implement” blink-dev discussion
https://groups.google.com/a/chromium.org/d/msg/blink-dev/5AgbvQwEEdM/bLQcXkF7BAAJ
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Interoperability Risk
Low.
The piping methods, like streams in general, have been the result of an active multi-vendor collaboration, guided the entire way by a large set of web-platform-tests which are co-developed with the specification and with other vendors. Readable streams have paved the way here with excellent interoperability, being deployed in Edge, WebKit, and Blink with compatible semantics, with Gecko following close behind.
The pipeTo() method is intentionally high-level in a way that hides most of its details. This allows behavior to vary between browsers in order to get optimal performance, but in well-constrained ways that should not cause developer surprise. Most of our recent spec work has been on properly balancing this intentional "slack" in the algorithm with the desire to ensure predictable behavior for developers; see this recent example. At this point we are happy with the balance.
Edge: no signals, although they have shipped readable streams with fetch
Firefox: Public support and actively collaborating on the spec repo
Safari: Shipped in 10.1. Their version is based on an earlier revision of the spec, but it is indistinguishable in normal usage; spec changes since then have been about adding optimization possibilities.
Web developers: Positive
Compatibility Risk
Low.
The related specification sections have been stable for some time. The Streams API is specifically designed to hide all activity while a pipe is ongoing, so as to allow implementations sufficient "slack" to implement aggressive optimizations in how they get data from the source readable stream to the destination writable stream.
You can view the issues being tracked in the spec repository. Besides issues around future features (tagged "V2"), we are working through some delicate phrasing around edge cases and brainstorming how to add more tests.
OWP launch tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=668951
Entry on the feature dashboard
https://www.chromestatus.com/feature/6067348976959488
Rick Byers
Jochen Eisinger
Chris Harrelson
LGTM1
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
