Re: [whatwg/streams] ReadableStreamDefaultController seems redundant (#743)

Hmm, I think I see what you're getting at.

It seems like ReadableStream doesn't know whether it wants specializations to be push-based or pull-based, and in trying to support both it gets complicated.

Normally, input streams are strictly pull and output streams are strictly push -- that is, after all, their defining difference. So the obvious/naive way to design ReadableStream would be to have its constructor to essentially take an implementation of Reader (or something close to it). getReader() could essentially return that object, while the other methods would be implemented in terms of it. That would then be a strictly-pull API.

So what about push? I think the main cases where you want a "push-based API for input" is when implementing a pull-based API would require a convoluted state machine. The usual case I run into is where, say, a ServiceWorker wants to generate a response body dynamically in script. It's much easier to write code for this that performs a series of write()s than to write code which responds to a series of read() calls.

I'm not sure this use case lines up with your "reads are non-side-effecting" model. I think that model really only aligns with true pull-based streams, not push-based code that is going into a queue to be pulled.

Maybe the right way to satisfy this use case is just to let people create a `TransformStream` that doesn't apply any transformation (effectively, just a pipe), and then write to the write end while passing off the read end to whatever needs it...

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/issues/743#issuecomment-300359928