W3C home > Mailing lists > Public > public-media-capture@w3.org > May 2015

Re: About onaddtrack/onremovetrack

From: Harald Alvestrand <harald@alvestrand.no>
Date: Tue, 26 May 2015 14:21:43 +0200
Message-ID: <55646557.5020902@alvestrand.no>
To: public-media-capture@w3.org
Den 26. mai 2015 14:02, skrev Adam Bergkvist:
> On 2015-05-22 22:49, Jan-Ivar Bruaroey wrote:
>> On 5/21/15 10:28 AM, Iņaki Baz Castillo wrote:
>>> 2015-05-20 20:19 GMT+02:00 Jan-Ivar Bruaroey <jib@mozilla.com>:
>>>> Events are synchronous, so when they happen in a synchronous call, should it
>>>> not happen before the call returns?
>>> I don't think that events should be synchronous. They may be called in
>>> future loop iterations after the function returns.
> 
> This is pretty much the issue. What is requested in this thread is an 
> async event similar to the one fired when the UA adds a track to a 
> MediaStream as a result of, for example, a network request.
> 
>>
>> I vote for least suprising, and think we should be consistent with the
>> rest of the web platform, unless we have a good reason.
> 
> I totally agree that we should be consistent with the web platform here, 
> but I'm not sure what that is. To be honest, the synchronous event 
> dispatch behavior of the focus event kind of surprised me.

Events (the basic primitive) are defined as synchronous.

Things that happen in the Web platform that are described as "Schedule a
task to fire an event...." effectively create asynchronous events. There
are a LOT of such descriptions.

I too was surprised when I read the spec and found that "fire an event"
means "call the handler functions for this event", not "cause this to
happen in the future".
I tend to think of synchronous callbacks as a spec bug, not a feature.
Received on Tuesday, 26 May 2015 12:22:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:33 UTC