Re: [whatwg/streams] Communication between workers/windows via Streams API (#244)

We've finalized the ReadableStream. Let's investigate the plans again based on the up-to-date ReadableStream design.

The 2 plans proposed are:
- (a) just allow postMessage()-ing ReadableStream
- (b) have a method to create a ReadableStream (WritableStream) to the caller and given the destination worker a WritableStream (ReadableStream) connected with each other

The key difference between them is whether the initiator creates/sees the stream for the peer or not.

(a) has the following topics to solve
- how to neuter the ReadableStream on the original thread
- whether we should postMessage()-ing a reader or a stream or both
- how much of the logic (ReadableStream, ReadableStreamDefaultController, ReadableStreamDefaultReader) should stay in the original thread

Because of these reasons, I proposed (b).

Regarding the 3rd point, I think it's no longer problematic. We need to fail it when chunks and an error object passed to controller.error() are not structured clonable, but except for them, ReadableStream class itself doesn't hold anything externally given. Queuing strategy and underlying source logic are now held by the ReadableStreamDefaultController instance. So, we need to neuter (public interface part of. if difficult, maybe just error it) the ReadableStream in the original worker, create a ReadableStream in the destination worker, connect them by some mechanism to transfer the protocol between the newly created ReadableStream and ReadableStreamDefaultController (with structure cloning).

We need to investigate pipeTo() optimization story before moving forward though. https://github.com/whatwg/streams/issues/359

---
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/244#issuecomment-227999124