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

> result.ab is a new reference. result.size is the number of bytes written.

This shouldn't be necessary since we can make `newBuffer` be of the partial size using that functionality of transfer, I think? Or maybe the result.ab/result.size design would allow concatenating into one large buffer, hmm.

But in general here are my thoughts.

> ```js
> let newBuffer = await rbs.readInto(ab, 0, ab.byteLength);
> // here, ab is neutered.
> return newBuffer;
> ```

This code is no longer nice, I think. That is, it no longer says what it means. Well, OK, first the name `readInto` is now wrong, so let's change that:

> ```js
> let newBuffer = await rbs.readBytes(ab, 0, ab.byteLength);
> // here, ab is neutered.
> return newBuffer;
> ```

It's still not very good however. Why are we giving `ab` to `readBytes` if it's just going to give us a new object anyway? What was the point of us creating it in the first place---why not just let `readBytes` create the array buffer fresh?

On the other hand, I think `feedArrayBuffer` is more do-what-I-mean:

```js
rbs.feedArrayBuffer(ab); // use this for next read of underlying source.
// since we fed it to the stream, it's not ours anymore, it just gets detached.

await rbs.ready; // wait until the next read completes (using any fed array buffers)

let newBuffer = rbs.read();
```

However I haven't thought through feedArrayBuffer very far yet in this new detaching world. I want to write some sample code that explains how to use it for the cases in my gist. Maybe it has the same limitations as readInto and doesn't give us anything new besides being a bit more "say what I mean." I will find that out tomorrow :). I will also look into the Promise<{ ab, size }> idea since that does seem promising now that I think about it.

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