Re: [whatwg/streams] Piping to writable streams with HWM 0? (#1158)

> Although adding such a mechanism might be useful, I want to make sure we've figured out the root issue here. In particular I worry that maybe we got the semantics of HWM wrong for WritableStream, if there's an expressive gap here.
>
> But, I'm having a hard time articulating the expressive gap. Let's say we had a WritableStream with HWM = 0 that called `controller.releaseBackpressure()`. (When would it call it, exactly?) What is that WritableStream trying to express?

I agree, it's tricky. I'm also still trying to wrap my head around it, it's not very concrete yet. 😛

I'm mainly coming at this from the `TransformStream` use case. Data written to the writable end will be queued and, when the readable end releases its backpressure, will be transformed and enqueued on the readable end. Similarly, read requests on the readable end *should* cause the writable end to also request some data if it doesn't have anything queued yet. But does that "write request" mean anything outside of the transform stream's use case?

This may also be necessary if/when we flesh out writable byte streams (#495), and (by extension) transform streams with readable/writable byte stream end(s). If we want "reverse BYOB" or "please use this buffer" semantics, then it would be nice if a BYOB request from the readable end could be forwarded to the writable end. But then the writable end is almost *required* to have HWM = 0, so it can wait for a read request to provide a buffer (instead of allocating one by itself). 🤔 

...Or maybe "reverse BYOB" is too weird, and a "regular" BYOB writer is fine. I don't know yet. 😅

> My best guess was something like "I currently have nothing in the queue, and I intend to consume whatever you give me ASAP, but please don't give me more than 1 chunk". But... that seems like the right semantics for HWM = 1. So I admit I'm confused.

With HWM = 1, the stream is asking to always put at least one chunk in its queue, and to try and hold back if it's not done processing that latest chunk yet. Here, most of the time `writer.ready` will be resolved. You write a bunch of chunks, `writer.ready` temporarily becomes pending while the sink works through the backlog and eventually `writer.ready` resolves again.

With HWM = 0, the stream is asking *not to put anything its queue*, except for the case where it *wants* a chunk. Here, most of the time `writer.ready` will be pending. When the sink eventually wants a chunk, `writer.ready` temporarily becomes resolved and waits for a chunk to be written. Once that happens, `writer.ready` becomes pending again.

They're similar, but with HWM = 1 the "default" state is for `writer.ready` to be resolved and the "transient" state is `writer.ready` being pending, whereas with HWM = 0 those states are reversed.


-- 
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/1158#issuecomment-895579099