Re: [whatwg/streams] Idiomatic Way to Explicitly Tell an Underlying Transform Stream to Flush to the Sink (#960)

Currently the way you'd do this is by having the Zlib transform decide for itself to flush based on a timeout. This is obviously not good as the transform has no context about whether to flush or not.

I assume we'd want this to work in a pipe. Consider this pipe:
```javascript
source
  .pipeThrough(a)
  .pipeThrough(zlib)
  .pipeThrough(b)
  .pipeTo(destination);
```
Who is responsible for issuing the signal? Only `source` knows that it doesn't expect to receive new data for a while, but only `destination` knows that it wants chunks ASAP.

I'm going to assume we get around that problem by telling `source` in some out-of-band fashion that we want it to issue flushes.

Sketching what the API would look like, `TransformStream` already has something called [`flush()`](https://streams.spec.whatwg.org/#dom-transformer-flush) so we'd have to use a different name. `sync()` seems as good as any. I expect the underlying source would call `controller.sync()` to indicate that it isn't expecting to have new chunks for a while. `pipeTo()` would convert this to a call to `writer.sync()`.

In order for the sync signal to pass through `a` without change, the default behaviour if `sync()` is not supplied should be to call `controller.sync()`. Or maybe the sync signal should *always* pass through a `TransformStream` regardless of whether `sync()` is defined or not.

`zlib` would have an implementation of `sync()` that flushes any currently buffered data, and passes on the sync signal. If `destination` was something like a buffered file, it might use the sync signal to flush any buffers to disk.

This is a lot of additional complexity, and we'd need some compelling use cases to justify it.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/issues/960#issuecomment-436500981