Re: Specifying the association with an online timing service

I'm a bit confused - I thought this was what we were discussing?  I.e. a
provider of a service (like Shared Motions) provide you with a vital piece
of information for your app - you have to handle changes to the service,
like it becoming ready, it being altered etc.  Hence, we would like to
ensure that the initial addEventListener triggers the current state of the
service (i.e. replay the last event) to avoid having potentially
complicated code to handle various special cases.

The suggestion is to avoid special cases by generalizing them - the event
listener will be triggered on registration if the event has already been
emitted.  Or it's just me being very confused today, possibly due to a too
low coffee intake!

N



---
Dr. Njål Borch
Senior researcher
Norut Tromsø, Norway

On 10 June 2015 at 14:05, Dominique Hazael-Massieux <dom@w3.org> wrote:

> On 10/06/2015 12:53, Njaal Borch wrote:
>
>>
>> The attached test does work, as it hooks everything up before the video
>> element becomes ready.
>>
>
> Right; this is what I was illustrating — code sequenced in a single
> execution task can't have underlying state changed under its feet.
>
>  Try adding a setTimeout around it, like:
>>
>
> Right; but setTimeout precisely creates a separate execution stack, in
> which case the JavaScript semantics I was alluded to no longer apply (by
> design, otherwise asynchronous code would be useless).
>
>         setTimeout(function() {
>>        var v = document.getElementById('v');
>>        v.addEventListener('canplay', function() {
>>          document.getElementById('log').textContent = 'ready to play';
>>        });
>>      }, 1000);
>>
>> Actually, with just 100ms delay, my FF often does not emit the event,
>> one second delay and it never does.  Chrome mostly emits it with 1s
>> delay, never with 2s...  FF is particularly faster on reloads, clearly
>> caching some data. So if you want to get the event consistently, you
>> will have to register for the canplay listener early enough.  There are
>> of course solutions (be faster, do the check and emit yourself), but we
>> can do this consistently by replaying the event on addEventListener. :-)
>>
>
> One you switch to an asynchronous mode of execution, you can't (and thus
> shouldn't) make any assumption about the order and timing of async
> operations.
>
> Dom
>
>
>