Re: [streams] Operation stream (#287)

Again, reply to Domenic's comment https://github.com/whatwg/streams/pull/287#issuecomment-76333828

> space/waitForSpaceChange are on writable stream. I guess they are more sophisticated versions of the current backpressure signal, of "writable" or "waiting", that can be used to communicate how much can be written. This makes sense.

Right.

> I think it mostly makes sense for WritableByteStream, because then when piping you could ask for as many bytes from the readable byte stream as space indicates on the target writable stream. Maybe it could make sense for general readable streams using their size() strategy method, but that is kind of complicated. E.g. it assumes compatible notions of size between the source stream and the target. Hmm.

Yes. There could be some translation between each pair of source type and target type, but not always so simple and worth to be abstracted in the streams library, I guess. For byte streams, yes, I think it would be useful.

> I don't quite understand window though. I imagine it maps to TCP window stuff but I don't understand that perfectly either :(. Could you help me understand it? And, how general is such an idea---just byte streams, or anything with a size, or...? Does it depend on the capabilities of the underlying source, so e.g. it works for sockets but not for files?

Right. It's inspired by TCP. For byte streams, we can specify how much data we want to receive from the remote host, read from kernel, read from other process, etc. using window. In some old thread, I said that I guessed it's not rare that we want to control the high water mark of the strategy from user code based on current situation e.g. back pressure from the sink the data read from the readable stream finally reaches. Basically, it's fine to understand this as a knob for adjusting hwm.

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/pull/287#issuecomment-76697646