Re: [streams] can streams be transferred via postMessage()? (#276)

@sicking That's a good question. In the end the answer is no: `pipeTo` operates polymorphically on its argument, which must take the structural type of a writable stream, but could be any implementation of the writable stream contract. (E.g., queue-backed `WritableStream`, or specialized `WritableByteStream`, or any author-created writable stream types.) This is discussed in some length [in a new section of the spec](https://streams.spec.whatwg.org/#other-streams); feedback welcome on that. In the end I think this is key to a thriving stream ecosystem with both specialization and generality built in.

However I of course recognize the impulse behind it; you want to have fast off-main-thread piping be the norm for UA-created streams talking to each other. I see a few perspectives on your question in that light:

- Modifying a UA-created writable stream in such a way "deopts" you to the normal pipe algorithm, since you have made it observable. This honestly seems fine to me; it's similar to how most JS objects work. (E.g. if you start adding numeric properties to `Array.prototype`/string-valued properties to an array, all arrays/that array will now be slow.)

- Alternately, we could say that it depends on the implementation of `readable`. If `readable` is a type of stream that knows how to recognize `NativeFileSystemAPIFileAppendWritableStream`s (or whatever), then its `pipeTo` implementation might be different than `ReadableStream.prototype.pipeTo`. E.g., as its first line it could do a brand-check to see if its argument is a `NativeFileSystemAPIFileAppendWritableStream`, and if so reach into its internals. This would of course mean `readable` is not a `ReadableStream`, but instead a more specialized type that has such additional logic. But that seems expected; if it has a different implementation, then it needs to be a different type.

- Going even further, we could try to make `ReadableStream.prototype.pipeTo` itself extensible in this fashion, thus avoiding the proliferation of types. That is, in the same way you want to have specialized piping algorithms for your UA-created streams, we should be able to explain that specialization mechanism and give authors access to it, since of course it's not only UA streams which could benefit from this specialization. There's a few approaches to this, including a double-dispatch one I spent some time typing up before realizing it was probably too complicated for this bug at this stage. But the simplest model is probably just a registry of `(rsBrandCheck, wsBrandCheck) -> pipeAlgorithm` which pipeTo can consult.

I'd be quite interested in an implementer perspective on which of these seems more attractive.

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/issues/276#issuecomment-86249915