Add an abstraction to pull from buffer into ReadableStream

[saschanaz]

Intended to fix the Fetch spec issue whatwg/fetch#1610.

• At least two implementers are interested (and none opposed): N/A, just moving existing steps from Fetch to Streams
• Tests are written and can be reviewed and commented upon at: Same
• Implementation bugs are filed: N/A
• MDN issue is filed: N/A

(See WHATWG Working Mode: Changes for more details.)

---

Preview | Diff

[domenic]

So one issue here is that this "buffer" type, and the operations on it, are undefined. The operations seem to be:

• "extracting from" which returns a byte sequence while presumably modifying the buffer;
• "size" which returns an integer; and
• "append" in fetch

I was OK with this as a one-off over in fetch, but since we're encountering this a couple times, we should think a bit harder about whether it's the route we want to go down. I.e., how should we represent underlying platform byte buffers in specs.

Options I can see:

• Leave it as-is in this PR. It's fine, probably people know what it means.
• Define a "platform byte buffer" type, probably in Streams, with a couple sentences describing what it generally corresponds to and explaining the two operations you can apply to one of these platform byte buffers.
• Use byte sequences instead. Then specs like Fetch would say something like "Let |buffer| be an empty [=byte sequence=]. NOTE: this represents the internal buffer inside the network layer of the user agent".

I think using byte sequences would be most reasonable. WDYT?

[saschanaz]

Good point! Using byte sequence sounds good to me. But we still have no definition for the operations, right?

[domenic]

Well, yes, but we have length. And I feel less bad about using common-sense definitions if the base type is well-defined. So:

• We can use length instead of size
• We can use "Append" because it's straightforwardly clear
• For "Extract", I'd feel better if we broke it down into "Let x be the first Y bytes of Z", "Remove the first Y bytes from Z". Then the common-sense definitions are very clear.

[domenic]

Thanks, this algorithm looks great now! I pushed a commit to move it around and integrate it with the rest of that section; if those changes look good to you, then I think we can merge.

[saschanaz]

LGTM, thanks for the cleanup!

[saschanaz]

Should we explicitly say the below algorithm doesn't enqueue "when they have more bytes on hand than ..."?

Also, w3c/webtransport#487 throws in that case, should it enqueue instead? Not sure it's fine to implicitly ignore the byob request view. Oh okay, it doesn't match what it wants in that case.

[domenic]

Added a note, thanks!