Re: [w3ctag/design-reviews] Writable Streams (#163)

@dbaron Backpressure is largely implicit, based on the principle that stuff should "just work". An underlying sink signals backpressure by not resolving the promise it returned from `write()` until the data has been written. I think this is the natural way for a `write()` implementation to behave anyway. An underlying source experiences backpressure as `pull()` not being called. Again, I feel it's natural that a source would not produce data until it is asked.

One point that perhaps could be stated more clearly is that for optimum throughput the `highWaterMark` that is set when creating a ReadableStream or WritableStream should reflect the burstiness and latency of the source or sink.

My hope is that `pipeTo()` and `pipeThrough()` will be the main interfaces used by the consumers of streams. These respond correctly to backpressure without any specific action needing to be taken.

I think the bitrate of a media stream needs to be set based on the throughput. Streams don't attempt to measure the throughput, leaving this to applications that need it.

Regarding

> At this point in time the division of work between the stream and its controller may seems somewhat arbitrary, but centralizing much of the logic in the controller is a useful structure for the future.

I believe this is because we intend to add a `'byte'` type of WritableStream in the future. I'm not sure why it doesn't just say that. Also, myself, @domenic and @tyoshino have considered the division of labour very carefully, so I think this statement could be worded better.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/163#issuecomment-297917561