- From: Adam Rice <notifications@github.com>
- Date: Thu, 21 Sep 2017 06:22:58 -0700
- To: whatwg/streams <streams@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Thursday, 21 September 2017 13:23:20 UTC
I've realised you can't reliably perform the "close the downstream, error the upstream behaviour" with the current API. `controller.close(); controller.error();` is equivalent to `controller.error()` if the readable queue is non-empty. The queued data will be discarded. I suppose you could poll `controller.desiredSize` until it is equal to highWaterMark and then call `controller.error()`. This seems bad. I've also become less convinced by my earlier argument that you should be able to keep receiving new chunks after calling `controller.close()`. I now think that `close()` meaning "I am done with transforming" makes more sense. I also don't think "close and discard" is sensible any more. If the source is infinite then continuing to read it at full speed seems like a bad idea. So I've come around to "close and abort" semantics. I don't know if we should change the name to `closeAndAbort()` for clarity, or stick with `close()` to avoid being ugly. `closeReadableAndAbortWritable()` would be the ultimate in clarity, but I don't think anyone would want to type that. -- 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/774#issuecomment-331154708
Received on Thursday, 21 September 2017 13:23:20 UTC