Re: [whatwg/streams] Should there be dedicated VideoFrame ReadableStream/WritableStream constructs (Issue #1187)

Following on last meeting discussion, a potential approach would be something like:
- Add a new type to ReadableStream/WritableStream/TransformStream, say 'transfer'
- If type is 'transfer', we apply the API contract we discussed for VideoFrame: controller.enqueue and writer.write take ownership of the object. In case of aborting a stream, enqueued values get cleaned up.

This makes the API contract very clear.
And there are additional good ergonomics (proper clean-up, tee would by default use structured cloning for this type).

Taking ownership could be implemented in various ways:
- If object is transferable, use transfer steps
- If object has clone/close methods, use these for transferring ownership and cleaning up.

The added complexity to the streams implementation seems mild.
We already have the type/readableType/writableType infrastructure in place.
We would have to store the 'transfer' type and update the enqueue/write/abort/transfer algorithms if type is 'transfer'.
One question might be whether this type should be queryable by JS.

One potential disadvantage happens for transferred streams.
In that case, if we allow random objects having custom close/clone methods, we lose the ability to call these methods in the transferred stream.
Maybe we should only allow streams of 'transfer' type to handle specific objects, say Transferable, with the possibility for a 'close-able' trait concept that would need to be defined.

Thoughts?

-- 
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/1187#issuecomment-972655674