Re: [streams] What should we call ReadableByteStream.prototype.getBYOBReader()? (#294)

> Domenic, what do you think about C? Is this kinda method to say "please read now, but decide how much to pull by yourself" to the reader?

Yeah, exactly. This would probably be done intelligently on a per-stream basis. IIRC libuv has heuristics for this (since Node streams are not BYOB), @piscisaureus mentioned them to me once.

It also says, "I don't care about reusing buffers, and will let the JavaScript GC take care of freeing the memory".

---

I am starting to think that an options-object accepting `getReader()` may be better. In case we add more dimensions of variability in the future, it would avoid a combinatorial explosion in method names. Let us think what that would look like:

- Byte stream
  - getReader({ feedBuffers: true, flowing: true }): throws
  - getReader({ flowing: true }): B
  - getReader({ feedBuffers: true }): A
  - getReader(): C
- Object stream
  - getReader({ flowing: true }): B
  - getReader(): C

Or maybe we want the default to be auto-pulling, so instead of `flowing: true` it is `manualPull: true`. (Better name?) Then we have

- Byte stream
  - getReader({ feedBuffers: true, manualPull: true }): A
  - getReader({ manualPull: true }): C
  - getReader({ feedBuffers: true, manualPull: false }): throws
  - getReader(): B
- Object stream
  - getReader({ manualPull: true }): C
  - getReader(): B

---

The interesting thing about object streams B vs. C is that previously we kind of let this be controlled by the strategy instead of by the consumer. (Although even then I think we always would be trying to pull at least some before exerting backpressure.) We could move that all to configuration to getReader?

Wait, but how does C work for object streams that are wrapping push sources? I think the `manualPull: true` only makes sense for: (a) APIs that are inherently pull-based like read(2)-on-files; (b) APIs that allow us to use the kernel buffer to store data (but that only goes up to a limit before we start losing data...) like recv(2)-on-sockets. But it does not work for APIs like web sockets that are pushing data at you via events and you will lose the data if you don't react...

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