Re: [streams] Port precise flow control to writable streams (#318)

Questions:

### What should we expose?

I see two choices:

- `queuedSize` = total size in the queue.
- `desiredSize` = high water mark minus total size in the queue. Can be negative or zero. Represents how much you should write right now.

### How should the `ready` signal work?

A few possibilities:

1. The current `ready` signal, which fulfills when queuedSize dips below the high water mark (or desiredSize goes above zero).
2. A different signal, call it `drained`, which fulfills when queuedSize reaches zero (or desiredSize reaches highWaterMark).
3. A generic `queuedSizeChanged` signal, which fulfills both when you write to the stream and when the underlying sink finishes consuming a chunk.
4. A more monotonic `queueSizeDecreased` signal (probably there is a better name), which fulfills when the underlying sink finishes consuming a chunk. The semantics here are a bit unclear to me honestly.
5. A customizable `.waitForQueueSize(n)` which waits for the queue size to dip below `n`, or `.waitForDesiredSize(n)` which waits for the desired size to go above `n`.

I am leaning toward the simplicity of (1) and/or (2). But (5) also works. I don't really like (3) or (4).

### Who should determine the high water mark?

We could do a few different choices:

1. Get rid of the high water mark entirely. Producers need to monitor `queuedSize` and adjust to their comfort level. Writable streams don't get to signal what they want.
2. As-is now, make it part of the queuing strategy, so that it is set at writable stream creation time by the stream creator.
3. Make it determined by `getWriter({ highWaterMark })`. This is essentially saying that high water mark is a way to save the producer some arithmetic over option (1). The producer would pass in highWaterMark = x and get back desiredSize, instead of getting back queuedSize = y and calculating desiredSize = x - y. See also #375.

I am a bit uncomfortable with (1) and (3) because I think many writable streams will have at the very least a desired chunk size that they would want to signal.

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