- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Thu, 03 Jul 2014 11:08:24 +0200
- To: public-webrtc@w3.org
I find Adam's argument compelling. This means that state changes track the firing of events, and may lag behind the changes in the underlying communications subsystem. But they will be delivered consistently, and for reasonably written applications (short callbacks), the lag should not matter. Let's document it that way. On 06/30/2014 12:01 PM, Adam Bergkvist wrote: > 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 Thursday, 3 July 2014 09:08:56 UTC