Re: About onaddtrack/onremovetrack

On 2015-05-18 10:32, Iņaki Baz Castillo wrote:
> 2015-05-13 8:35 GMT+02:00 Adam Bergkvist <adam.bergkvist@ericsson.com>:
>> The reason you get a close event when you do close() on a WebSocket is
>> because you initiate the closing handshake (state: CLOSING) and the
>> event tells you when it's completed (state: CLOSED).
>>
>> I believe it's not common to fire events as a result of direct
>> manipulation of objects.
>
> RTCPeerConnection.close() fires "onsignalingstatechange" event
> (pc.signalingState = closed). I don't think it's so uncommon.

Correct me if I'm wrong, but I don't think it should according to the 
specification.

>> The task that fires an event is usually the
>> task that modifies the concerned script objects and the reason for the
>> event is to notify what happened. It's not compatible with a synchronous
>> operation that performs its action directly.
>
> I don't agree. Call close(), and react on the event listener. That is
> very common in many libraries and APIs.

I think that's true when a closing procedure is initiated by the close() 
call (like WebSocket), but not when it's a "hard" close (like 
EventSource). I believe this is the approach with standardized web 
platform APIs, I can't speak for JS libs in general.

Generally speaking, one reason for not firing events together with 
synchronous operations is that by the time the scheduler picks up the 
task that fires the event, the state may have changed synchronously 
again. The result is that the event doesn't reflect the correct state 
when fired. For example, an addtrack event fires with track as it's 
payload, but the track is no longer present on the MediaStream. That's 
why state updates are made synchronously by the task that fires them; so 
the event properly reflects the state it's supposed to when fired.

/Adam

Received on Tuesday, 19 May 2015 05:39:21 UTC