- From: Boris Zbarsky via GitHub <sysbot+gh@w3.org>
- Date: Mon, 11 Dec 2017 21:46:40 +0000
- To: public-webrtc-logs@w3.org
> So in Nightly we've implemented getSynchronizationSources() without implementing the voiceActivityFlag I should note that our IDL for this dictionary in Firefox nightly looks nothing like spec's in various ways... > you could probably argue we shouldn't have implemented anything until we'd implemented all the fields I'm not making that argument. I'm making the argument that _if_ it's expected that implementations will want to ship `RTCRtpSynchronizationSource` without implementing `voiceActivityFlag`, _then_ the spec should make provisions for doing so and explain clearly how such UAs should behave, so they behave interoperably in that situation. > What's the rationale for avoiding required-but-null on outputs? We already have a perfectly good way to indicate "this information is not available": a non-required dictionary member that is not present. Adding a _different_ way to indicate that information makes the web platform more complicated (now consumers have to worry about three separate possible states, or more, depending on how other specs decide to represent "not available, but we're forcing the property to be present anyway". Are there practical reasons a consumer would want to differentiate "the browser is not providing us this information because it doesn't want to" and "the browser wants to provide this information but can't"? Those are basically what you suggest undefined and null map to, right? -- GitHub Notification of comment by bzbarsky Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1689#issuecomment-350868843 using your GitHub account
Received on Monday, 11 December 2017 21:46:41 UTC