Re: [whatwg/streams] Add support for ReadableStream "transfer" type (PR #1271)

> * The current algorithm tries to transfer/serialize only if it is sure to be able to enqueue. This seems a good property to me.

Agreed.

> * If transfer/serialization fails, we silently terminate without either throwing or erroring the stream. I wonder whether this will be surprising to web developers.

I would lean towards erroring the stream. Silently losing data is something I want to avoid.

> * Cloning a `transfer:true` stream with transfer-only objects would succeed but the second branch would be errored. This seems ok to me.

It makes me a bit uncomfortable but I think it's acceptable.

> * The current transfer-or-clone algorithm has surprising and potentially undesired effects:
>   
>   * `enqueue(videoFrame)` would make sure to transfer videoFrame but `enqueue({ videoFrame })` would clone it.
>   * We could introduce a second optional parameter to controller.enqueue, something like `enqueue(any message, sequence<object> transfer = [])` and update accordingly the `StructuredTransferOrClone` algorithm. This would make it closer to postMessage. In that case, should we keep `enqueue(videoFrame)` as a shortcut to `enqueue(videoFrame, [videoFrame])`?

If we add two-argument `enqueue()` we should also add two-argument `write()`. I would like the two-argument form to work even when not using `type: transfer` as it is extremely useful in combination with transferable streams. When I was thinking about this previously I was concerned about the extra complexity it adds to `pipeTo()`, but maybe it's really not that bad now that we use `ReadRequest` internally.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/pull/1271#issuecomment-1504737985
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/streams/pull/1271/c1504737985@github.com>