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

> We talked about various ways of attaching a strategy to a WritableStream after it had arrived in the destination context, for example with an attachStrategy() method.

This is interesting, but seems pretty un-ergonomic.

> We discussed changing postMessage() to be able to specify what the strategy would be on the destination side, but it doesn't really fit into the API.

Even if we put it in, I'm not sure how it would solve the essential problem that you can't transfer functions across threads :(.

> I brought up the issue that write(chunk) should perform the transfer synchronousl

Agreed. This and your subsequent conclusions all make sense.

An alternate approach would be to do two transfers: one same-realm that transfers from the producer's control into the internal queue on the sender side, and one that transfers from the sender side to the receiver side. Not sure if that's better.

> We concluded that if we do not have transfer() as part of the strategy, then the best way to customise the strategy in the transferred stream is just to put a TransformStream in front of it with the desired strategy.

I'm not quite sure I follow this case.

> We also discussed what happens if you try to transfer locked streams. Ideally postMessage() would throw.

Oh, definitely. To be transferable you need a [[Detached]] slot, and the contract is you're supposed to set that to true once you get transferred, so that future attempts to transfer (or clone) throw. So on a spec level at least this is pretty much a given.

> Maybe this also applies if IsDisturbed() is true?

I still see IsDisturbed as kind of weird. But maybe the reasons we had for using it in fetch also apply here? I dunno.

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