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 - see issue #23.
I would also like to suggest that the timingobject has .clock property making its reference clock explicit.
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 - see issue #23.
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