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]

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.