Intent to Prototype: Streams API: Byte Streams

208 views
Skip to first unread message

Nidhi Jaju

unread,
Oct 20, 2020, 8:38:45 PM10/20/20
to blin...@chromium.org, Adam Rice, Yutaka Hirano

Contact emails

nidh...@google.comri...@chromium.orgyhi...@chromium.org

Explainer


Specification

Streams API Spec

Design docs

We will update this thread when our design doc firms up.

Summary

The streams APIs provide ubiquitous, interoperable primitives for creating, composing, and consuming streams of data. For streams representing bytes, an extended version of the readable stream is provided to handle bytes efficiently, in particular by minimizing copies.


Blink component

Blink>Network>StreamsAPI

Motivation

Byte streams allow for BYOB readers to be acquired. The default implementation can give a range of different outputs such as strings or array buffers in the case of WebSockets, whereas byte streams guarantee byte output. Furthermore, being able to have BYOB readers has benefits in terms of stability. This is because if a buffer detaches, it can guarantee that one does not write into the same buffer twice, hence avoiding race conditions. BYOB readers also do not need to garbage collect for every read, because we can reuse buffers.


Initial public proposal

None

TAG review


TAG review status

Not applicable

Risks

Interoperability and Compatibility

Low risk because it has already been standardised for a long time (since around 2014). Other browsers have implemented other parts of the standard, and they will most likely also adapt byte streams as well soon.


Gecko: No signal
WebKit: No signal
Web developers: No signals

Ergonomics

A lot of design efforts have been made into making the streams API easy to use. Additionally, this byte streams API is similar to the existing streams API that developers are used to.


Activation

It is difficult to polyfill just byte streams, without polyfilling the rest of readable streams. Hence, developers may need to wait for other browsers to also implement byte streams, or maintain two code paths.


Debuggability

No special support needed.


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes. This feature will be purely implemented in Blink and so cross-platform support is automatic.

Is this feature fully tested by web-platform-tests?

Yes

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=614302

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4535319661641728

Lennart Grahl

unread,
Oct 21, 2020, 4:24:12 AM10/21/20
to blink-dev, Nidhi Jaju, Adam Rice, Yutaka Hirano
Apologies for the noise but it's great to finally see this. :)

yo...@yoav.ws

unread,
Oct 22, 2020, 11:39:01 AM10/22/20
to blink-dev, Lennart Grahl, Nidhi Jaju, Adam Rice, Yutaka Hirano
On Wednesday, October 21, 2020 at 10:24:12 AM UTC+2 Lennart Grahl wrote:
Apologies for the noise but it's great to finally see this. :)
On Wednesday, 21 October 2020 at 02:38:45 UTC+2 Nidhi Jaju wrote:

Contact emails

nidh...@google.comri...@chromium.orgyhi...@chromium.org

Explainer


Specification

Streams API Spec

Design docs

We will update this thread when our design doc firms up.

Summary

The streams APIs provide ubiquitous, interoperable primitives for creating, composing, and consuming streams of data. For streams representing bytes, an extended version of the readable stream is provided to handle bytes efficiently, in particular by minimizing copies.


Blink component

Blink>Network>StreamsAPI

Motivation

Byte streams allow for BYOB readers to be acquired. The default implementation can give a range of different outputs such as strings or array buffers in the case of WebSockets, whereas byte streams guarantee byte output. Furthermore, being able to have BYOB readers has benefits in terms of stability. This is because if a buffer detaches, it can guarantee that one does not write into the same buffer twice, hence avoiding race conditions. BYOB readers also do not need to garbage collect for every read, because we can reuse buffers.


Initial public proposal

None

TAG review


TAG review status

Not applicable

Why?

Nidhi Jaju

unread,
Oct 23, 2020, 1:59:50 AM10/23/20
to yo...@yoav.ws, blink-dev, Lennart Grahl, Adam Rice, Yutaka Hirano
Hi Yoav,

We were initially planning on not to do a TAG review because byte streams have been standardised.
However, we have now decided to do the TAG review, so I am currently in the process of working on it.

Best regards,
Nidhi

Nidhi Jaju

unread,
Oct 29, 2020, 9:44:21 PM10/29/20
to blink-dev, yo...@yoav.ws, Lennart Grahl, Adam Rice, Yutaka Hirano
Just updating this thread with the explainer and TAG review links.


Best regards,
Nidhi

Nidhi Jaju

unread,
Nov 3, 2020, 11:46:04 PM11/3/20
to blink-dev, yo...@yoav.ws, Lennart Grahl, Adam Rice, Yutaka Hirano
Updating this thread with the link to the design doc as well.


Best regards,
Nidhi
Reply all
Reply to author
Forward
0 new messages