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

Domenic: Oh, OK. I'll think about revisiting everything. But for now, I'm optimistic about sync read(). Like `.feedArrayBuffer()`, we could add, say `.feedReadToken()` to ReadableStream to allow users to manually control how much objects to pull. In the "precise flow control" world I envisioned, these pull/read separated interfaces are the base than the current ReadableStream in the spec.

Current ReadableStream is relieving users from doing this manually by having an automatic feeder named "strategy". Current ReadableByteStream is relieving users from allocating ArrayBuffers manually by allocating them automatically but with size=underlyingByteSource.readBufferSize. I'd view them as easy to use variants of the base interface, ManualBufferFeed.*.

It looks that the pros/cons of the promise-returning version you've sketched in https://github.com/whatwg/streams/issues/253#issuecomment-74114680 are:

- pros
    - we ask everyone to use the same interface while covering various kinds of underlying sources efficiently
    - pull (read()) and read (fulfillment of the promise) are associated. we can map request-response semantics to it
- cons
    - more microtasks
    - I'm not fully sure if there're real use cases, but separation of pull and read basically gives users more degree of freedom. This approach loses it since pull and read are associated.


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