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

> The socket example doesn't actually want to wait for pullInto at all. Does this seem right to you? (I'm really really sorry if we've discussed this before and are going in circles :()

Oh, nice analysis! Yeah, the socket API has the following characteristics:
- readable notification
- read-into style reading
- nothing corresponds

This matches the byobRequest model well since read request notification and outstanding request getter are separate.

> First, maybe it should be c.byobRequest.buffer + c.byobRequest.respond() or something, just for clarity.

Good idea.

> But more importantly, it means that in some cases an underlying byte source might not have pullInto. I guess the fix for this is to add an explicit boolean like { start(), pull(), byob: true }. And either pullInto present implies byob: true or you get an error if you forget byob: true but also supply pullInto.

OK! The number of arguments increases, but it's clearer how the byte / non-byte distinction is made.

> Maybe we just merge pull and pullInto??

I'll give it a try.

> microtask isn't a big deal

Just to be clear, I'm not concerned with the cost (time) of the microtasks, but API cleanness. We need to manually enqueue a microtask to see if the pullInto happens or not. If such pullInto doesn't happen, the manually created task will be executed next. You know that pullInto didn't happen and proceed to run `controller.enqueue()`. My concern was that we shouldn't ask the implementor to wait for 1 microtask "manually".


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