- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Mon, 14 Dec 2020 20:43:46 +0000
- To: public-webrtc-logs@w3.org
> It's a bit too minimal. The slides were more clear. Readers could misconstrue "consistent" to mean "the same". I was a bit vague on purpose since we're not adding any "MUSTs" this late in the game. Alternatively we could say that you are not allowed to remove any capability from the set of capabilities after exposing them and still allow adding to the set of capabilities when finding out about more hardware. So if you were overly-optimistic in the past then you have to be overly optimistic in future calls as well, even after finding out a codec doesn't exist. This would prevent IllegalModificationError while still allowing more flexibility by the implementation. However if we give an implementation the flexibility to add to the set of capabilities over time, then: 1. You're better off parsing SDP than calling getCapabilities(). 2. The usefulness of getCapabilities() is implementation-specific and not interoperable. 3. getCapabilities() is supposed to be "the most optimistic view of the capabilities" but if it under-reports initially that does not sound very optimistic. So I'm not sure interpreting "consistent" as "the same" is a bad idea, but I'm also not sure we want to explicitly say that "the same" is the only valid option without revisiting this in webrtc-extensions. So... this is hairy. Feel free to edit this PR. -- GitHub Notification of comment by henbos Please view or discuss this issue at https://github.com/w3c/webrtc-pc/pull/2617#issuecomment-744699011 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 14 December 2020 20:43:48 UTC