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

On 2014-06-30 11:00, Harald Alvestrand wrote:
> 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?
>

Hi

I don't know if we should invent something new in this particular area. 
Our case is not that unlike that of XMLHttpRequest, where the progress 
of the request is reported as a set of (sometimes rapid) state changes 
(UNSENT, OPENED, HEADERS_RECEIVED, ...). It would be hard to write 
meaningful code if this behavior wasn't consistent and predictable.

The way this works in the platform is that when the user agent wants to 
tell the script about a state change, the user agent queues a task on 
the JS event loop that updates the state attribute and fires the event. 
The queue of state changes is already in there.

/Adam

Received on Monday, 30 June 2014 10:02:13 UTC