- From: Ian Denhardt via GitHub <sysbot+gh@w3.org>
- Date: Thu, 18 Nov 2021 19:52:01 +0000
- To: public-webrtc-logs@w3.org
@lgrahl, I still myself have a preference for just throwing in the constructor, but @annevk objected to introducing a new place where errors could occur. I agree it would be much simpler to get the language right in that case. @annevk, how strongly do you feel about this? I'm doubtful that there are many real world use cases where the extra error will be a problem; it would be limited to cases where an app tries to use WebRTC when the server operator has disabled it, which is already likely to be rare, and I can't imagine such an app could do more than fail with a better error if the authors have an existing error handler. I'm willing to defer to consensus here, but this very much feels like the wrong side of the trade-off to me. --- wrt @alvestrand's comments, I agree we should tweak the language to more explicitly block all network communication. I believe with this interface an implementation shouldn't ever *need* to do network communication; it should be able to just skip even looking for ICE candidates, since it knows all of them will be filtered out. But we should spell out that that behavior is required. I'll see if I can fuss with this soonish. That said, @annevk if you are at all open to the simpler solution of throwing in the constructor I still like that better. -- GitHub Notification of comment by zenhack Please view or discuss this issue at https://github.com/w3c/webrtc-extensions/pull/81#issuecomment-973207441 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 18 November 2021 19:52:03 UTC