- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Fri, 25 Oct 2024 20:20:44 +0000
- To: public-webrtc-logs@w3.org
> I'm not opposed to supporting transferability. Great! Since you said tracks are useless on workers except for the worker API, does this mean you support the worker API? > I'm opposed to making it a requirement to use mediacapture-transform, ... It already is a requirement. > ... as that will have the practical consequence of delaying interoperable implementations. I doubt attempting to standardize a third new API and waiting for three implementations will get us to interop quicker. Safari has shipped, and Firefox is working on it. 1½ < 3 + one WG. I've filed https://github.com/w3c/mediacapture-extensions/issues/158 to help. Creating a permanent web API to solve one implementer's short-term scheduling seems against [§ 1.7. Add new capabilities with care](https://w3ctag.github.io/design-principles/#new-features) and [§ 1.9. Leave the web better than you found it](https://w3ctag.github.io/design-principles/#leave-the-web-better). > This doesn't mean applications are forbidden from transferring tracks on browsers that support it if they want to. Having web developers navigate between 3 instead of 2 different APIs to do the same thing sounds worse, not better. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-transform/issues/113#issuecomment-2438724474 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 25 October 2024 20:20:45 UTC