Re: Summary of API for ICE State Reporting

On Aug 26, 2012, at 11:47 AM, Harald Alvestrand <harald@alvestrand.no> wrote:

> On 08/26/2012 06:58 PM, Cullen Jennings (fluffy) wrote:
>> 
>> I've tried to distill a bunch of the ICE state conversation into a proposal for the API to discuss on the conference call. Slides attached.
>> 
>> We probably need between 25 and 45 minutes on the conference call to sort this out
> 
> Cullen,
> 
> in your proposal B - is this intended to be equivalent to having 3 separate Booleans that can be queried, with events triggering     whenever one of them changes state?

so it's not really three booleans. Each function returns a tri-state instead of bi-state. So isChecking can indicate one of three return values 1) all the ice machines are in that state, 2) some of the ice machines are in that state 3) none of the ice machines are in that state. 

Randall said something to me on the call the other day that was both obvious and brilliant and totally cleared up my thinking on this. The events don't have to be connected with a change in the observable state - only the unobservable state. So when a new thing gets connected, the browser creates an event for that even though the value of isConnected might be the same as it was before. 


> 
> In the case when you have 3 ICE state machines, the first one is in Connected, the second one is in Checking, and the third one goes from Checking to Connected, I think you're saying that there will be an event triggered, but none of the booleans change state - so I guess not.

Yes, the JS app would get an event but none of the state functions that are observable in JS would have changed. 

> 
> Would the events have to carry information about the transport they refer to in order to be useful?

Perhaps - but all the event would need to carry is the list of tracks that the event applies to. I don't think we need to export up the transport info. 

> If so, would we have to expose a transport abstraction up to the PeerConnection interface to support that abstraction?
> 
> So far, we've managed to not do that. This could change.

I'm hoping we can not expose the transports abstractions anywhere except the statics API. I don't want developers to have to have to think about transports. 

> 
>                    Harald
> 
> 
>

Received on Monday, 27 August 2012 14:19:28 UTC