Re: [streams] What types does ReadableByteStream's reader's read(x) accept and return? (#295)

In prototyping, I found that:

- accepting TypedArrays with non-1 BYTES_PER_ELEMENT, and
- returning how many bytes have been filled by adjusting the size of the view (multiple of BYTES_PER_ELEMENT)

complicates the library much.

- I think it's common that we pass ArrayBufferViews of different types to the same ReadableByteStream (E.g. read one Uint32 containing the number of polygons, and then read Float64Arrays of the number * 3). So, we should support this kind of use case.
    - Then, in what data type should the view passed to the underlying byte source? As-is? Maybe ok. It's the underlying byte source's responsibility to fill the view passed through the `pullInto` interface and call `controller.respond()` with the same TypedArray with an adjusted viewed range.
- But, how about `controller.enqueue()` (see https://github.com/whatwg/streams/issues/353)? `controller.enqueue()` may have been called with insufficient bytes. E.g. Float64Array of 1 element is passed to the BYOB reader after just one enqueue() with 2 bytes as Uint8Array was done by the underlying byte source?
    - One simple solution is to error the stream when the underlying byte source enqueues a chunk that isn't aligned to match the data type the consume expects (as represented by the TypedArray type passed to the BYOB reader).
        - I think we shouldn't do this. E.g. TCP socket may deliver chunks cut at arbitrary points, even if the server sends aligned data.
    - So, what we should do for the case "2 bytes in queue, a Float64Array came". Should we do
        1. Call pullInto with `new Uint8Array(view.buffer, 2, 6)`?
        1. Call pullInto with a tuple of `view`, 2?
        1. Wait for enqueue()s enough to fill at least one element in the view?

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