- From: guidou via GitHub <sysbot+gh@w3.org>
- Date: Fri, 10 Jan 2025 18:47:26 +0000
- To: public-webrtc-logs@w3.org
> What flexibility was removed? The flexibility to manage the control surface and the media surface independently. > My [shim](https://jsfiddle.net/jib1/zocw86m3/) suggests the API proposed here is a subset of the existing spec, not a superset. The shim hasn't established that. It shows that you can postMessage around and have similar semantics for applyConstraints, which is an asynchronous operation. But that's not necessarily true for all control operations. For example, `stop()` and `enabled` are synchronous. Blocking the main thread to provide the same semantics while messaging across threads can have a nontrivial cost in terms of user-perceived performance. Event handlers probably also have their own set of issues. > What major problems? The evidence presented here suggests a minor inconvenience at worst. Having to redesign applications because they have to abandon the well-established assumption that they can control tracks on Window is not a minor inconvenience. It's evidence that the API is failing to properly support its intended use cases. > The spec follows established patterns for workers, which is postMessage, not bespoke cross thread APIs. What you call "bespoke" is a pattern established on the Web by this Working Group for the WebRTC Encoded Transform API. And among established patterns on the Web, it is not a bad one IMO. -- GitHub Notification of comment by guidou Please view or discuss this issue at https://github.com/w3c/mediacapture-transform/issues/113#issuecomment-2583569547 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 10 January 2025 18:47:27 UTC