Ben Kelly

> The problem with using a Transform to accomplish this is that the transform's writable stream would have to apply no back pressure to consume new values, which wouldn't work...

Can you draw another diagram? It sounds like you are talking about a completely different use case and source now. If the source in the previous diagram is pull, then...

We need a mechanism like I describe in #384. Imagine something like this: ``` var latch = new TransformStream({ latchedValue: null, pendingRead: null, transform: function(chunk, enqueue, done) { if (this.pendingRead)...

In the meantime, do you have a proposal API change that you think would solve your problem? Can you show some example code that you want to be able to...

Would it be enough to provide an "opportunistic read()"? This call would return any enqueued chunks, but not trigger a new pull on the underlying stream. When your downstream consumer...

> If we switch to callbacks, we will probably just run into the problem of the callback being called too often. FWIW, I did some prototyping to try to benchmark...

Also, in theory progress for any request is observable via the Response body stream in a service worker handling the FetchEvent.

I feel kind of strongly we should just allow `postMessage()` of the `ReadableStream`. I thought we had preliminary agreement to this affect in #276. If someone wants a WritableStream they...

Sorry, I see your last comment in #276 now. Maybe we have more agreement than I realized.

The URL returned by `createObjectURL` is reusable, but a `ReadableStream` is consumable. This mismatch is my main objection to this. I don't think we should create more implicit buffering in...