Re: [timingobject] Timestamps and reference clocks

Hi Francois. 

I think you have managed to convince me that your proposal is more 
intuitive :)

My suggestion was based on the "need to know" principle that the user 
agent should not have to know about the timeline used by the timing 
provider since it strictly does not have to.

I quite agree though that a floating t_init is somewhat weird concept 
- even if the math is correct.

With your suggestion - the useragent gets both t_init and t_now in the
 provider timeline. This is enough for calculating the diff, but as 
the timingobject.query() operation should return timestamps from the 
performance.now timeline,  t_now from the timing provider needs to be 
translated. 

I think the easiest solution would be if timingprovider did this 
translation as part of its .now() method.

ts_now_provider <- timingprovider.now(ts_now_useragent)

timingprovider.now() takes a timestamp from useragent timeline as 
parameter and returns corresponding timestamp from timingprovider 
timeline. (maybe "now" isn't the correct name any more)

I see your point of simply exposing the clock of the timing provider, 
and then let the useragent manage its own clock and synchronize it 
with the provider clock. This gives more flexibility to the user 
agent. I'm a bit worried though that having two clock-sync processes 
(first timing provider and then user agent) instead of just one might 
make the end result less precise. The errors from the first should 
dominate errors from the second - but I don't have the competence to 
say for sure if this is completely safe.

In the interest of airing all possibilities; it would also be possible
 to avoid clock sync completely in the timing provider, and instead 
have it simply relay request-response messages on behalf of the clock 
sync algorithm running in the user agent. I suppose this would limit 
the design space for timing providers.

What do you think?


Njål also pointed out another thing to consider. The query operation 
needs to be very cheap - and ideally it should be able to complete 
without consulting the timingprovider at all, as it may be running in 
a different thread. This is possible in your approach. It would also 
be possible if the timing provider provides the skew as an observable 
property.

And another thing.

How about the timing provider object managing N timing resources 
instead of just one?


-- 
GitHub Notif of comment by ingararntzen
See 
https://github.com/webtiming/timingobject/issues/16#issuecomment-134339451

Received on Monday, 24 August 2015 18:57:57 UTC