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

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