Re: [whatwg/streams] TransformStream probably doesn't need two strategies (#190)

What I'd like to do is use the equivalent of `CountQueueingStrategy({highWaterMark: 0})` for the `readable` and then pass the second argument to the TransformStream constructor directly to the WritableStream constructor to be the `writable` strategy. This will make TransformStream simpler to use, simpler to test and simpler to implement.

One thing is holding me back: what if the `transform()` method is "lumpy"?

By "lumpy" I mean that the time it takes is not consistent: sometimes it is fast, and sometimes it is slow. I'm sure someone has a better word for this concept.

When a source is lumpy, the creator of the ReadableStream object can use a strategy with a larger queue to compensate and the consumer of the data will get a smooth flow. Similarly, if a sink is lumpy you pair it with a larger queue and then the user of the WritableStream doesn't have to worry about it. It would be symmetrical if TransformStream had the same property.

However, if the readable side has a HWM of 0 then there will be no "transform ahead" and anything reading from the transform will experience the lumpiness directly.

Making the `readable` strategy configurable and the `writable` strategy fixed is not attractive because a WritableStream has to have a non-zero HWM in order for backpressure to work. Where you have a non-zero HWM it's really good to be able to set the `size()` methods on both sides of the pipe to be the same so that `pipeTo()` can perform a queue-merging optimisation. Also, if the side that's writing to the `writable` experiences lumpiness then that is not good either.

-- 
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/190#issuecomment-322984222