James M Snell

I don't actually think QUIC's design violates these ideas. The data flow is still one-to-one between producer and consumer, and in-line errors, data, and EOF are still in the same...

Hmm that could work. Let me stew on it.

The more I think about it the more I think we won't need the multiple reads for quic. So I think we can completely avoid the complexity in that case....

`give()` works

Yes, absolutely

`Stream(source, transform, sink, options)` ? In JS, `options` would be an object, in C++ it can be XOR flags.

Thinking about it further, you're right, `options` are likely not necessary here. I didn't really have any concrete suggestions in mind beyond some basic future proofing, but having it there...

For the JavaScript side, I think returning a thenable is completely reasonable. For the equivalent C++ API, passing in a callbacck function works just fine.

Another suggestion tho it makes the protocol slightly more complicated. QUIC uses a nice pattern where errors can actually be namespaced. It allows us to avoid needing to reserve error...

Well, I can illustrate by pointing to QUIC at least. With QUIC, there are generally three kinds of errors: Protocol, Crypto, and Application. The Crypto errors are a reserved range...