Re: [streams] Byte streams: write up design rationales and vision for how they are used/what they enable (#177)

>  source calls delegate.enqueue() to enqueue an ArrayBufferView to the [[queue]] 

I wonder if we should have the stream implementation enforce the type as Uint8Array.

> If the bytes are not sufficient to fill up view fully, source.read(newView) is called where newView specifies the not yet filled region

Alternately, we could just fill up view as much as possible, and have the returned ArrayBufferView be of a shorter byteLength. Just like if read(2) returns a smaller number of bytes than were passed in.

The more interesting case is: if [[queue]] is not empty, but its first chunk is of a larger size than `view`. Then we need to copy part of that chunk into `view` and leave the rest in the queue---at least, if implemented in JS. (C++ implementers might have more tools available, to avoid copies, and instead just make the returned Uint8Arrays map to the right memory regions.)

Agreed with everything else. Good detailed analysis.

It's interesting how much shared infrastructure there will be between ReadableByteStream and ReadableStream. I wonder if ReadableByteStream does end up just being a subclass after all. Hmm.

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