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

@yutakahirano 

> reforming ReadableStream's API largely because of a platform issue on ReadableByteStream seems not correct.

I understand where you're coming from. But I think it's a bit more than that. In general we design APIs are around platform limitations. The unfortunate discovery of this thread was that sync read is less flexible than async read. This is actually fairly common, to design something async even though some platforms could make it sync---e.g. `navigator.getBattery()` is promise-returning because for multi-process browsers it would require IPC, whereas single-process browsers (like the original implementation, in Firefox) used non-promise-returning `navigator.battery`. So in retrospect I feel kind of silly for not realizing it.

Regarding ReadableByteStream's impact on ReadableStream, I think it's pretty important to think of them as related. If we were in Java for example, there might be an IReadableStream interface defining the base contract, and then both ReadableStream and ReadableByteStream would implement IReadableStream. (Maybe it would be clearer if ReadableStream were named ReadableQueueStream!?) In JS we don't have a formal concept of an interface but the conceptual concept is still there: we want APIs to be able to accept "IReadableStream"s and process them, no matter whether they be ReadableQueueStreams or ReadableByteStreams. (Use case (1) in my previous post.) APIs that only accept ReadableByteStreams (use case (2)) can use the extra APIs. But we still want to enable ReadableByteStreams to be passed to IReadableStream consumers.

@tyoshino OK this is very interesting. Fairly minimal and gives more power. So it might win over simple async read()/readInto(). Let's flesh it out.

> ```js
>   // Controls how much data to pull. For queue-backed ones, this corresponds to
>   // the high water mark. Set a positive integer to pull or 0 not to pull. It
>   // depends on each implementation whether the size of the positive integer is
>   // interpreted or not. Initially set to 0.
> ```

Can we tie the `value` to the stream's notion of "size", as governed by the strategy? So, we still let the stream creator judge size of objects. But now we let the stream consumer set the high water mark.

> ```js
>   // Feeds an ArrayBuffer with region specification. The next pull is done with
>  // the specified buffer. If window has ever been set to non 0, throws.
>  feedBuffer(uint8Array)
> ```

Is this supposed to take a "region specification" (= offset, count, I think?)? Or does it reuse the window that was set? If so maybe it still needs to take an offset? Or are you using Uint8Array instead of ArrayBuffer specifically in order to get a region specification built in? If so that's interesting, not sure what I think of it...

> ```js
>   // Reads bytes available for synchronous reading, stores them into the given
>  // Uint8Array and returns the number of bytes stored (can be less than the
>  // size of the specified region).
>  readInto(uint8Array)
```

How does this interact with the buffers it was fed? I am unsure whether readInto is actually necessary at all given feedBuffer() + read(). See https://github.com/whatwg/streams/issues/253#issuecomment-73929164.

Other big questions:

- **I would really like to see examples of (all), (chunkwise), and (ping-pong) for ReadableByteStream**. I would also like to see evidence of how to set up a ReadableByteStream so that I can pass it to a consumer which doesn't know that the chunks are bytes (e.g., a progress bar consumer).

- I would like to see what this design gives over async read/readInto.

---

Separate question, @tyoshino: in https://github.com/whatwg/streams/pull/275#issuecomment-73470112 and https://github.com/whatwg/streams/issues/253#issuecomment-74052102 you said you think read(2)-backed ReadableByteStreams will be backed by a one-element queue. I don't quite understand why this would be the case? It seems better to have readInto() (or, maybe, feedArrayBuffer()) directly call to read(2), instead of having the queue.

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