Re: [streams] Generalized and precise flow/buffer control (#301)

I agree with the first post. In https://github.com/whatwg/streams/issues/294#issuecomment-81557090 I summed it up in terms of a proposed `.getReader({ queueSize: x })` API. And yeah, it is best-effort, with the underlying source implementation taking it into account to decide what to actually do.

On the second post, I also agree that there should be no necessity of connecting the view directly to ReadFile or similar. But just in case it wasn't clear, I think it's important to design the stream + underlying source constructor parameter combo so that you *could* code the underlying source purely in JS. That is, let's say we had almost-direct JavaScript bindings of syscalls (like [this for files](https://blog.domenic.me/reading-from-files/) or [this for sockets](https://blog.domenic.me/reading-from-sockets/)). Good underlying source code would still have to do more work, e.g. if the socket buffer is overflowing then the underlying source needs to copy into user-space and then later instead of reader.read() going directly to the syscall it copies the previously-saved buffer. But the important thing is that you could in theory express it all in JS using the underlying source constructor parameter + appropriate syscall bindings. So in this world e.g. `underlyingSource.read(view)` w
 ould have code to check any previously-copied stuff, and if not would call through to the syscall. Make sense?

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