W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2014

State changes: Is it important to know the exact sequence of state transitions?

From: Harald Alvestrand <harald@alvestrand.no>
Date: Mon, 30 Jun 2014 11:00:51 +0200
Message-ID: <53B12743.3060004@alvestrand.no>
To: "public-webrtc@w3.org" <public-webrtc@w3.org>
At a couple of point in the API, we have callbacks that are fired each 
time a state changes:

- onsignalingstatechange
- oniceconnectionstatechange

Both of these have the Event interface, which has no argument.

There's no guarantee how long a callback takes - it might be 
near-instant, it might be milliseconds, it might be seconds, or even (in 
the case of stupidly calling alert() from a callback) minutes.

Now, if two state changes happen in rapid succession (which they will 
often do), what is proper behaviour?

1) Make the state change when it happens. Let the callbacks fire when 
they can.
2) Make the first state change, call the callback, and delay recording 
subsequent state changes until the callback returns.

The last one seems .... uncomfortable .... to me.

The first one has the consequence that the callback will observe the 
current state, not the state that it was fired in response to. So for 
very transient states, they might never be observed at all.

There are two possibilities to resolve this without introducing queues 
of state changes:

1) The precise state sequence is not important. Observing the current 
state is good enough.
2) The precise state sequence IS important. The callback needs to be 
sent the precise state the transition is for as an argument.

I don't write much code that uses these callbacks. What is the opinion 
of people who do write such code?

          Harald
Received on Monday, 30 June 2014 09:01:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:59 UTC