Re: [streams] [WIP] Putting a chunk back in the readable stream queue (#275)

For RBSs that are not ArrayBuffer-queue-backed, we could add an attribute, say `.amountReadable`, on `ReadableByteStream` using which we can probe how much data can be read out synchronously. (If the underlying byte source is a socket, we can't determine that without `read(2)`-ing, so I'd like to make it able to have it return something indicating "I don't know".) This allows us to allocate sufficient but not too big ArrayBuffer to pass to `.readInto()`.

@wanderview If the ReadableByteStream is queue-backed (and ArrayBuffers are stored in the queue) like ReadableStream, then we want to look at the ArrayBuffers queued as-is than reading into the ArrayBuffer we brought with. Maybe this is what motivated you to add `peek`.

The benefits of `.peek()` are the following:

1. reduce buffer/state management by relying on the Streams library
1. [For ArrayBuffer-queuebacked RBSs] read data directly from the ArrayBuffers in the queue but without telling the Stream to pull the number of bytes in the read data

(1) can be realized even by `.readInto()` and `.amountReadable`. (2) is not.

For non-ArrayBuffer-queue-backed RBSs, `.readInto()` + `.amountReadable` would be :

1. more efficient in terms of the number of copies if the destination API wants to receive a single contiguous ArrayBuffer (not fragments represented as a list of ArrayBufferViews)
1. more efficient in terms of the number of ArrayBuffer allocations

In my old W3C Streams API spec, I allowed users to control how much bytes to pull precisely than replenishing quota for all the bytes in the output of `read()`. Do you think we should just add `.peek()` or more precise quota replenishment control would be useful considering complexity?

I guess addition of `.peek()` doesn't complicate the library much. I'm ok with that.

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/pull/275#issuecomment-73470112