Re: [streams] How will ReadableByteStream work with seekable resources? (#253)

If the blocking I/O:

- accepts a buffer
- based on the size of the given buffer, controls how much data it pulls from the source

Then, we want to allow the user code to allocate a buffer with size determined based on their status. To realize this, yes, we need some API like `readIntoAsync()`. But between `ready + read()` and `ready + readInto(ab, offset, sizeDesired)`, I don't think there's so much difference. `ready + read()` doesn't know what size is appropriate. 1MiB may be too big or too small. The only disadvantage of `ready + readInto()` for this kind of I/O is an extra copy (internal buffer to user allocated buffer).

In what form can we provide `readIntoAsync()` together with `read()`? To allow sync `read()` we have on the `ReadableStream`, we need to pull data from the source at least when we're in the `"waiting"` state. Otherwise, we never enter `"readable"` state. But this spoils the `readIntoAsync()`'s benefit. We'll have some data already pulled (to serve for `read()` user) when `readIntoAsync()` is called.

So, we need to add some interface to suppress automatic pull when we want to use `readIntoAsync()` style reading?

----

If the blocking I/O:

- tells us how much data is readable on unblocking
- and then, accepts a buffer

Then, `ready + read()`'s

- pros: can avoid using too small buffer (includes cost of leftover merging as you say, etc.). can avoid allocating too big buffer.
- cons: the user cannot limit size to read. all available data will be passed to the user code.

(I assumed that the unblocking event leads to fulfillment of `ready`, and `read()` allocates a buffer with suitable size and populates it)

For this case, there's no big difference between `readIntoAsync()` and `readInto()`, I think.


---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/issues/253#issuecomment-70489666