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

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

I think in practice implementations will want to do only one transfer, to avoid walking the object graph twice. Unless it makes the standard hugely more complicated, I'd rather spec it the way browsers will implement it.

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

Let's say a developer transfers a readable stream to a worker, and wants to have 64 KB of buffering in the worker in addition to whatever buffering is configured in the main page. Then it would work just as well to write
```javascript
const rs = transferredReadableStream.pipeThrough(
  new TransformStream({}, new ByteLengthStrategy({highWaterMark: 65536})));
```
as to write
```javascript
rs.addStrategy(new ByteLengthStrategy({highWaterMark: 65536}));
```
So there's no need for an API like `addStrategy()` to exist to support this use case.

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