Re: [streams] Finalize pull/pullInto behavior (#423)

This basically means, once a pull happens, you keep doing pull until desiredSize = 0? And, once a pullInto happens, you keep doing pullInto until .... when?

> Hmm what is the advantage of byobRequest over an argument?

With desiredSize, an underlying source can probe how much data there is in the queue. So, the source can fill the queue in a single pull().

```
c.enqueue();
if (c.desiredSize < ...) {
  // enqueue more data
}
```

The source doesn't have to wait for another pull() to know the queue still has free space. This was previously realized by the return value of the enqueue() method, and now is implemented by desiredSize.

----

Suppose that we're in a pullInto invocation. We just enqueue()-ed or respond()-ed the pullInto. If highWaterMark is set to e.g. 1024 byte, desiredSize returns 1024 byte. But now the stream still has one more read(view) pending. The source's policy is that it wants to fill a given ArrayBuffer (provided via pullInto args) if any, but otherwise, wants to fill the queue by enqueue(). Without `byobRequest`, we need to invoke pullInto again to notify the source that there's one more read(view). The source needs to wait for 1 micro task to see whether such pullInto occurs or not to decide whether it should use enqueue() or not (use respond() in response to pullInto).

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