[timingobject] Adding a clock object to the spec

ingararntzen has just created a new issue for 
https://github.com/webtiming/timingobject:

== Adding a clock object to the spec ==
The timing provider exposes a *.vector* property that includes a 
*.timestamp* property (unit:seconds).
This timestamp is sampled from the *timing provider clock*. In 
addition, the timing provider exposes a *.skew* property 
(unit:seconds) that relates the *timing provider clock* to the *user 
agent clock*, through the following equation: *timing provider clock* 
= *user agent clock* + skew. The *user agent clock* is defined as 
performance.now()/1000.0 (unit:seconds). 

This makes it possible for the timing object to transfer timestamp 
values back and forth between the two timelines (defined by the two 
clocks). For online timing providers, the *.skew* property will be an 
estimate, possibly fluctuating slightly, so the timing object will 
have to integrate these fluctuation into its calculations.

Currently the spec mixes these calculations into the pseudocode 
specification of internal functionality.

However, I'd like instead to suggest adding an explicit *clock* object
 to the spec, to encapsulate the complexity of these timeline 
transformations. So, the *clock* would be a local object representing 
the external *timing provider clock*. This clock would then receive 
dynamic skew changes and base its calculations on the latest *skew* 
estimate,.

This *clock* object would effectively be the reference clock used by 
the timing object. The timing object could use timestamps samples from
 this clock directly in calculations with the vectors it receives from
 the timing provider.

The *clock* object would also serve as a global reference clock 
associated with a particular timing provider.

Another point is that timeouts (i.e. setTimeout) in applications 
ideally should be relative to this *clock* object instead of the 
system clock. This is especially true for online timing providers, 
where fluctuations in *clock* may cause timeouts too be a few 
milliseconds early or late, possibly much more for long timeouts due 
to relative clock drift. By having an explicit *clock* object it is 
possible to make a revised timeout mechanisms that is sensitive to 
this issue. The *clock* object may for instance emit *change* events 
to trigger re-evaluation of timeouts. This has been done for the 
Sequencer implementation in the timingrc implementation [1].
 
Finally, an explicit *clock* object opens the door to allowing 
multiple timing objects to share reference to the same *clock* 
instance, avoiding duplication of this task across multiple timing 
objects.

I would also like to suggest that the timingobject has *.clock* 
property making its reference clock explicit.

[1] 
[http://webtiming.github.io/timingsrc/doc/index.html#sequencing](http://webtiming.github.io/timingsrc/doc/index.html#sequencing)
 


Please view or discuss this issue at 
https://github.com/webtiming/timingobject/issues/22 using your GitHub 
account

Received on Wednesday, 24 February 2016 14:24:42 UTC