Some ideas came up in conversation with @wanderview in IRC today and I thought would be worth logging.
The first is a potential readBatch(numberOfChunks) method that would allow you to wait for multiple chunks at once. This would presumably return a promise fulfilled with an array. Empty array, or array of less than numberOfChunks length, would mean you reached end of stream. The motivation here was performance though (on the theory that it'd be more efficient for the underlying source to assemble an array of chunks and then deliver in one promise, rather then having consumer code extract from multiple promises then reassemble into an array). And performance arguments are weak without data. My instinct is to push this off into the future.
The second was the question of how read(view) works for BYOB readable byte stream readers. I had been envisioning it as doing a direct pass through to the underlying byte source. So for example for files, you'll usually get back view.byteLength bytes (unless at the end of the file), whereas for sockets, you'll get back some unknown number of bytes <= view.byteLength. However, we could instead say that the underlying source needs to either fill the entire view or close the stream. (I am not sure we could enforce this programmatically, but it could be something we advise underlying source implementations to do, and in particular fetch body stream.) We could even add an option that lets you toggle between the behaviors.
Some ideas came up in conversation with @wanderview in IRC today and I thought would be worth logging.
The first is a potential
readBatch(numberOfChunks)method that would allow you to wait for multiple chunks at once. This would presumably return a promise fulfilled with an array. Empty array, or array of less thannumberOfChunkslength, would mean you reached end of stream. The motivation here was performance though (on the theory that it'd be more efficient for the underlying source to assemble an array of chunks and then deliver in one promise, rather then having consumer code extract from multiple promises then reassemble into an array). And performance arguments are weak without data. My instinct is to push this off into the future.The second was the question of how
read(view)works for BYOB readable byte stream readers. I had been envisioning it as doing a direct pass through to the underlying byte source. So for example for files, you'll usually get backview.byteLengthbytes (unless at the end of the file), whereas for sockets, you'll get back some unknown number of bytes <=view.byteLength. However, we could instead say that the underlying source needs to either fill the entireviewor close the stream. (I am not sure we could enforce this programmatically, but it could be something we advise underlying source implementations to do, and in particular fetch body stream.) We could even add an option that lets you toggle between the behaviors.