Design Review #567

#567: Byte Streams

Opened Oct 29, 2020

HIQaH! QaH! TAG!

I'm requesting a TAG review of byte streams.

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

Explainer¹ (minimally containing user needs and example code): https://github.com/whatwg/streams/blob/master/byte-streams-explainer.md
Specification URL: https://streams.spec.whatwg.org/ Specific Sections:
Tests: https://github.com/web-platform-tests/wpt/tree/master/streams/readable-byte-streams
Security and Privacy self-review²: https://docs.google.com/document/d/15nhR1drg4qEip041RcBFWEFbDjv-5EJc-zsgaON49Zo/view
GitHub repo (if you prefer feedback filed there): https://github.com/whatwg/streams
Primary contacts (and their relationship to the specification):
- Nidhi Jaju (nidhijaju), [Google]
- Adam Rice (ricea), [Google], Spec Editor
- Yutaka Hirano (yutakahirano), [Google], Spec Contributor
- 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: https://github.com/whatwg/streams/issues/300, https://github.com/whatwg/streams/pull/430
External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): https://chromestatus.com/features/4535319661641728

Further details:

I have reviewed the TAG's API Design Principles
Relevant time constraints or deadlines: No specific deadlines.
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: N/A
This work is being funded by: Google

You should also know that...

N/A

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

Discussions

Comment by @atanassov Nov 23, 2020 (See Github)

@nidhijaju a few of us are looking at your Explainer during our breakout session today. It would be helpful to provide a bit more information so we can engage more efficiently and make progress. In particular - what are your explicit goals and non-goals of the feature? What other options have you considered when choosing the API? What is the exact API that you're proposing? Thanks.

Comment by @nidhijaju Nov 25, 2020 (See Github)

Hi @atanassov, I have updated the explainer based on the questions you asked, so hopefully that helps provide some more clarification. Please let me know if there's anything else that you might need. Thank you!

Discussed Dec 7, 2020 (See Github)

Yves: still trying to figure out how it differs from regular streams. For example "bring your own buffer" is already in the streams spec.

Dan: there has been an update to the explainer after Rossen's feedback.

Hadley: kind of missing user needs... End user...

Dan: Agree - we should ask them to be clear about what the user benefit is...

[hadley leaves comment]

Comment by @hadleybeeman Dec 8, 2020 (See Github)

Hi @nidhijaju. We're looking at this in a breakout session. Could you please spell out the user benefit or user needs in your explainer? (This is for the end user, rather than the developer.) For example, if it's all about making things faster, that's worth making explicit — and also specifying what 'things' you have in mind there. Many thanks!

Comment by @nidhijaju Dec 9, 2020 (See Github)

Hi @hadleybeeman, the end-user benefit is that it will increase speed and lower memory usage for sites that take advantage of it. Specifically, sites that handle streaming binary data will see improved performance. I've also updated the explainer with this information, so hopefully that helps answer your question. Thank you!

Discussed Jan 11, 2021 (See Github)

Dan: Maybe the lowest-level API we've tackled.

.. December 8, Hadley asked the requester ... user benefits/user needs.

... responded, "increase speed and lower memory usage for sites that take advantage of it. Specifically, sites that handle streaming binary data will see improved performance."

Ken: How would developers figure that out?

Sangwhan: People who need this will use this.

Yves: It says it's there to avoid multiple copies in memory for the same buffer.

... Another example of very low-level optimisation in a higher level API, not that great. Would rather have other ways of achieving that optimsation like ??? in Linux, a view of data that is streamed in memory space, don't need a copy but can take a pointer at a given location. Not sure something analogous is possible in JS

... A bit ugly, but could be useful for something like a node application for example.

Ken: what is the alternative today?

Yves: Copy.

Ken: This is just about trying to avoid having several copies...

Yves: Reducing copies. Copying between buffer and stream.

Sangwhan: Can byo buffer, don't need to worry about GC

Yves: Also controlling size of buffer.

Ken: I had assumed the BYO buffer thing already existed...

Dan: Two WHATWG bugs on streams that they point to in service of answering question about multi-stakeholder review. e.g. bytestream bug 300... where does this indicate multi-stakeholder review? Lot of stuff around Chromium.... developed by Google engineers, being pushed into WHATWG, we're being asked to review because of blink process. Trying to figure out what the multi-stakeholder story.

Sangwhan: Doesn't look like Anne has looked at it, which is worrying.

Dan: I don't see anything in either of these bugs that talk about multi-stakeholder review.

Ken: Jake Archibald should have a look at this. Should we @-mention Anne and Jake?

... I can do that.

Dan: I'll leave a comment asking about multi-stakeholder feedback.

Yves: Other than the low-level optimisation in a high-level API, it looks ok. I can add that comment.

Ken: I wonder what the actual use case that triggers people to work on this feature.

Comment by @kenchris Jan 12, 2021 (See Github)

Hi @annevk and @jakearchibald - it would be great with your knowledge, feedback and potential concerns about this proposal.

Comment by @torgo Jan 12, 2021 (See Github)

Hi @nidhijaju - and happy new year! We're just picking this up again. You mentioned a couple of WHATWG threads in response to the question on multi-stakeholder feedback, however I don't see any obvious evidence of multiple implementations there. Is there for example a Mozilla standards position on this?

Comment by @annevk Jan 12, 2021 (See Github)

No concerns here. This has been part of the Streams standard for a long time and it was always part of the goals to provide performant I/O streams that integrate well with Typed Arrays. (See https://github.com/mozilla/standards-positions/issues/457 and https://github.com/mozilla/standards-positions/pull/464 for Mozilla's position.)

Comment by @jakearchibald Jan 12, 2021 (See Github)

Seconded!

Comment by @ricea Jan 12, 2021 (See Github)

@torgo Chrome's is the first browser implementation, however there is an independent TypeScript implementation here: https://github.com/MattiasBuelens/web-streams-polyfill/tree/master/src/lib/readable-stream.

Comment by @ylafon Jan 27, 2021 (See Github)

Not a fan of mixing higher level APIs and low-level optimisations, would prefer to have optimisation hints for the VM instead to make it more efficient, but as this API will only be used by people needing it right now...

Comment by @annevk Jan 27, 2021 (See Github)

I think it's the ~ same as why we have Array and ArrayBuffer. VMs can do a lot, but for certain performance needs they need help.