- From: Adam Rice <notifications@github.com>
- Date: Tue, 23 Jun 2020 09:55:24 -0700
- To: whatwg/streams <streams@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/streams/issues/276/648287943@github.com>
I've thought about special-casing double-transfer a bit more and now understand why it's hard. The problem is setting up the initial state of the transferred stream. A normal transfer involves setting up a special kind of identity transform that communicates over a message pipe. We pipe the original stream into the local end, and the remote end becomes the transferred stream. There are two key features of this 1. The only thing we actually need to transfer is one end of a message pipe, and 2. The initial state of the original stream is copied to the transferred stream implicitly via the use of pipeTo(). Now in the double-transfer case we'd like to reuse the message pipe embedded in the transferred stream, transfer it again, and use it to create the doubly-transferred stream in the target realm. Which works fine if the transferred stream happens to be in its default state, but if it's in some other state that won't be correctly reflected in the doubly-transferred stream. So this second transfer involves transferring not just a message pipe, but the complete current state of the stream. So we have two choices, 1. Have two very different ways of setting up the remote proxy stream, or 2. Remove the current elegant method and only have an ugly method, possibly removing the "special identity transform" and pipeTo() and instead proxying the underlying source methods directly. Neither of these options are particularly attractive. I would prefer to ship the first version of transferable streams without special-casing double-transfer at all, but if we are going to change the whole approach then we should probably decide it now. -- 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/276#issuecomment-648287943
Received on Tuesday, 23 June 2020 16:55:36 UTC