Takeshi Yoshino

It's been a while, Hirano-san, Adam-san! Sounds reasonable not to work on this for the 1st version. The change LGTM. Feel free to just close this issue for now, or...

> However, I find it basically impossible to envision author code using this correctly and consistently. I agree it's not easy to use. The user must be aware of some...

We could also manually do the equivalent by using a stream of tuples of `{ value, resolve, reject }` and a strategy that looks at `[[value]]` when calculating size.

Seems the proposal at https://github.com/whatwg/streams/issues/329#issuecomment-106780286 (see also https://github.com/whatwg/streams/issues/329#issuecomment-112673762) allows users to ignore complicated APIs (`getByobReader()` and `getBufferLendingReader()` (i.e. reader for read with ack)) and just use `getReader()` while allowing use...

Thanks for the feedback, domenic, ricea. I'm fine with the plan.

Can you elaborate the use case? Initially we need `b` but at some point `b` becomes unnecessary? What's going on in piping is basically not observable from the streams API....

If the cookie decrypter is designed to become `"closed"` when it sees the end of headers, we can use `pipeTo` with the `preventCancel` parameter set to **true** to get notified...

This is a proof-of-concept code snippet for my answer to the optimized piping vision. Basically brain dump + a little validation of solidness.

OK. I forgot to note but this is intended to be used just for demonstrating that our API enables this kind of optimization. Not necessarily intended to be a part...

Extended the API a bit to address the flushing issue I discussed in the last comment.