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

Hmm, I see. That seems to basically work, as far as I can tell...

So as much as I like (2)'s ergonomics, it seems like both (1) and your version of (3) are more workable. Let me comment on why I think the disadvantages are OK in both cases, before going to sleep:

On (1):

> "Opportunistic greedy transfer" algorithm needs to be specified somewhere.

Not a big deal. I think we'd integrate it into StructuredSerializeWithTransfer, which already is doing object-graph crawling.

> Can lead to surprising behaviour for deeply-nested objects, for example

Since this is opt-in on the stream level, this seems fine. (I.e., we aren't applying this to every ReadableStream.) It seems like an OK thing to say that passing your chunks to a transferred readable stream means that not only will you never see the readable stream again, you'll never see your chunks again.

On (3):

> There's no way to explicitly say that the top-level object is transferable.

Hmm, OK, this is an issue. Somehow I missed this earlier.

Right now I'm feeling `[Symbol.transferable]: '*'` vs. `[Symbol.transferable]: ['value']`.

> Not clear what the meta-protocol should be.

I think you've answered this :).

> Probably requires the most standards and implementation work of any of the options.

Not so bad. The hardest thing is picking a place to park the symbol. (I'm not sure putting web platform stuff on `Symbol` is a great idea.)

Once we've done that, it's similar spec work to (1); we need to insert some steps into StructuredSerializeWithTransfer.

It does have more wide-ranging _effects_, but the spec and implementation work should be similar, I think: just add some extra auto-discovery-of-transferableness steps inside the existing graph-crawling.

-- 
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-383790050