- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Mon, 20 Nov 2023 11:07:52 +0000
- To: public-webrtc-logs@w3.org
> It seems like a footgun to me. There are examples of this pattern and it does not seem to cause issues to web developers. For instance, RTCPeerConnection.ontrack, ServiceWorkerGlobalScope.onfetch, MediaStream.onaddtrack. Following on those existing APIs, these would probably reference the same track objects (although we could expose a method if we really wanted separate tracks). > what application needs to decide dynamically whether it wants to source-inject or not? From a web app point of view, being able to decide at point of use, and not at point of registration, is usually a good thing. Say the web application is broadcasting via WebRTC and optionally (via a user toggle) recording the local screen. The web application could for instance decide to use source-injection for WebRTC and new tracks for local recording. Or it could decide to use source-injection if switching from one screen to another, but would not do this if switching from/to a window. A web developer can optimise a bit potentially by telling it would never call `preventDefault()` via `passive`. Also, the event-based approach is better from an extensibility point of view. These are examples of advantages of reusing the existing Event based ecosystem. These advantages should be compared to spec/implementation complexity. I think the major complexity here is to support both models, which we seem to agree on. The point in time where to select the model can bring some complexity, probably limited though. -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/255#issuecomment-1818841139 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 20 November 2023 11:07:54 UTC