- From: Taylor Brandstetter via GitHub <sysbot+gh@w3.org>
- Date: Thu, 16 Mar 2017 19:02:40 +0000
- To: public-webrtc-logs@w3.org
> Users will expect that everything that comes out from the onicecandidate event can be thrown into addIceCandidate without having to check anything. I see the argument that new users would expect that... Current users are I believe accustomed to checking `candidate != null` though. > I still don't understand why the onicecandidate returns null There are applications that use this `null` candidate event as a signal that candidate gathering is done, so they can get a new description with the full set of candidates and send it to the non-trickle-ICE aware endpoint. > It also breaks forward compatibility towards addIceCandidate as the method allows candidate to be null but the description does not handle that case. How does it allow `candidate` to be `null`? `candidate`'s type isn't nullable anywhere I can see. Anyway, I agree what we have now is confusing; it's the result of making the minimum possible changes to allow the end-of-candidates indication to work, and not breaking backwards compatibility. Do you think the confusion could be cleared up by summarizing the different candidate signals somewhere? Or should we reconsider the choice to keep around the `null` candidate event? -- GitHub Notification of comment by taylor-b Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1077#issuecomment-287159303 using your GitHub account
Received on Thursday, 16 March 2017 19:02:46 UTC