- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Tue, 28 Mar 2023 14:53:19 +0000
- To: public-webrtc-logs@w3.org
Our concern is that the API allows hardcoded inputs, which if it becomes a prevalent pattern causes implementation-dependent failures, and web compat headaches for non-dominant browsers in particular. This is consistent with https://github.com/w3c/webrtc-extensions/issues/130, where we mitigated the risk by requiring input that was harder to hardcode by accident (by requiring the same array length as that of getter output). Unfortunately, that doesn't work here, since setCodecPreferences has different (don't use) semantics for missing entries. It's worth noting https://github.com/w3c/webrtc-extensions/issues/130 was resolved without resorting to vending platform objects. Switching to platform objects would cause its own headaches, like making it harder to partially shim these APIs, unless we provide a constructors for the platform objects, but then the mitigation isn't that strong. Given all that, I see a strong argument to align with existing implementations here, and a match algorithm like the one proposed in #2847 might be the right direction, but would like to hear from @youennf since I believe the WPT with hardcoded codec came from Safari? But it's not clear from the PR whether we are: 1. Cementing codec comparison to ALWAYS be by `clockRate`, `mimeType`, `channels` and `sdpFmtpLine`, _and no future members_, or 2. We intend to extend the comparison algorithm in the future to include future members. If it's 2, don't we risk breaking existing sites? Also, if it's 2, we can simplify the algorithm to compare ALL members so we don't need to update it in the future. @Orphis -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2845#issuecomment-1487044576 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 28 March 2023 14:53:21 UTC