Re: [webrtc-rtptransport] Should RtpSendStream/RtpReceiveStream be transferable? (#36)

> this uses a standard JS pattern with which developers are already familiar, rather than needing to learn the semantics of another api-specific "one off transfer"

Yes and no.
First, both models are in use. From past experience, web developers had no issue understanding the one off transfer model.

Second, the semantics of the "one off transfer" are simpler to understand. With the transferability approach, web developers may need to understand:
- where these objects can or cannot be transferred (service workers? iframes? out of process dedicated workers?)
- when these objects can or cannot be transferred (e.g. can it be transferred if an event handler was set?)
- what happens when object gets transferred while being in use (will events or packets be forgotten/buffered/fired during transfer)
- what the state of the 'neutered' object is
No need to understand any of those things with the "one off transfer" approach, API is self explanatory.

In that same vein, if we want to extend these objects in the future, we would need to design these API extensions with transferability as a constraint.

-- 
GitHub Notification of comment by youennf
Please view or discuss this issue at https://github.com/w3c/webrtc-rtptransport/issues/36#issuecomment-2114792850 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 16 May 2024 10:12:59 UTC