Re: icecandidate event with no candidate

On 4/26/13 6:27 AM, Justin Uberti wrote:
>
>
>
> On Thu, Apr 25, 2013 at 1:23 AM, Adam Bergkvist 
> <adam.bergkvist@ericsson.com <mailto:adam.bergkvist@ericsson.com>> wrote:
>
>     On 2013-04-25 06:36, Justin Uberti wrote:
>
>         In the Lyon discussion, we specifically agreed to use
>         onicecandidate(null) rather than invent a new callback for the
>         icegatheringstate change, as it was felt that such a callback
>         would be
>         redundant, and would also not meet all the needs of the
>         trickle-ice
>         proposal.
>
>
>     Yes, that was our decision at the time. I'm just forwarding
>     feedback from developers who think it's a bit strange and
>     unintuitive. Especially with regards to the name of the event and
>     how similar things work in other APIs.
>
>
> Understood.
>
>
>     How would a separate "gathering done"-event not meet all the needs
>     of the trickle-ice proposal?
>
>
> Because it needs to know when each transport (m= line) is done 
> gathering, not just when it's completely done. onicecandidate could be 
> tweaked to do this by surfacing a Candidate object with the m= line 
> info filled in, but no candidate.
I guess you could just as well have a "gathering done" event per 
transport. You have obviously identified a need to know when gathering 
is done per transport. Do you think we should also expose the connection 
state per transport (and not only for the entire PeerConnection)?

Stefan
>
>
>     /Adam
>
>
>
>