- Finally, in order to support precisely timed operation in multi-device applications, the timing object must be connected with an online timing resource. One could imagine future standardization of a protocol between timing object and the online timing service. Currently though, the decision is rather to leave space open for innovation among timing providers. The timing provider interface is introduced, see timing provider. The idea is that third parties may provide different implementations of timing provider objects (JavaScript), to which timing objects may then connect. As a result, the connection to a timing provider may be provided by the inclusion of a third party JavaScript library. + Finally, in order to support precisely timed operation in multi-device applications, the timing object must be connected with an online timing resource. One could imagine future standardization of a protocol between timing object and the online timing service. Currently though, the decision is rather to leave space open for innovation among timing providers. The TimingProvider interface is introduced (see ). The idea is that third parties may provide different implementations of timing provider objects (JavaScript), to which timing objects may then connect. As a result, the connection to a timing provider object may be provided by the inclusion of a third party JavaScript library.
@@ -369,10 +369,14 @@
- A timing resource is an object. This object essentially implements the abstraction of a linear motion in real time. For example, imagine a point moving along an axis. At a specific moment in time, this point has a specific position on the axis, a specific velocity and a specific acceleration. These three properties (all floating point values) define the state of the timing resource at that moment in time. Implementation of timing resources depends on the user agent providing an internal clock which is both precise, high-resulution and monotonic. [[HR-TIME]].
+ The performance clock refers to the precise, high-resolution, and monotonic clock defined in [[!HR-TIME]] (and exposed through the Performance.now() method).
+
+ A timing resource is an object. This object essentially implements the abstraction of a linear motion in real time. For example, imagine a point moving along an axis. At a specific moment in time, this point has a specific position on the axis, a specific velocity and a specific acceleration. These three properties (all floating point values) define the state of the timing resource at that moment in time.
- A timing resource may either be an internal timing resource, an object under the control of a user agent, or an external timing resource, an object under the control of a timing resource provider. Both types exist locally in the user agent, but the external timing resource may be a proxy object for an online timing resource, i.e. an object hosted remotely by an online service. + A timing resource may either be an internal timing resource, an object under the control of a user agent, or an external timing resource, an object under the control of a timing resource provider. Both types exist locally in the user agent, but the external timing resource may be a proxy object for an online timing resource, i.e. an object hosted remotely by an online service.
A user agent may typically offer native implementations of timing objects, especially when the protocol needed is not available to Web applications. For instance, the clock synchronization mechanism defined in DVB for companion screens and streams [[DVB CSS]] uses a UDP-based protocol. A user agent could perhaps expose a DVBCSSTimingObject interface to allow Web applications to connect to a companion screen that supports this protocol.
@@ -555,11 +559,19 @@
+<<<<<<< HEAD A timing object has an internal clock which is [[HR-TIME]]. If the timing object is associated with a timing provider object, the timing object additionally has an internal clock skew. This represents the current estimate of the skew between the clock of the timing object and the clock employed by the timing provider. The internal clock skew is provided by the timing provider object, and defined so that clocktiming provider = clockuser agent + skew. This equation is used by the timing object to convert timestamps between the timelines of the two clocks. The timing object must ensure monotonic behavior by, if necessary, applying skew changes gradually.
A timing object has an internal vector that represents the initial conditions of the current motion. The internal vector is used by the query() operation to calculate a snapshot state vector of the current motion. If the timing object is associated with a timing provider object, the internal vector is provided by the timing provider and therefore includes a timestamp value from the timeline of the timing provider.
+=======
+ A timing object has an internal clock which is a monotonic clock. The internal clock is the performance clock if the timing object is not associated with a timing provider object. If the timing object is associated with a timing provider object, the internal clock is a logical clock that the user agent dynamically adjusts to follow the updates made by the timing resource provider to the skew property of the timing provider object. The skew is an estimation of the difference between the timing resource provider clock and the performance clock, so that clocktiming provider = clockuser agent + skew. The user agent must ensure the monotonicity of the logical clock by applying skew changes gradually, if necessary.
+
+ A timing object has an internal vector that represents the initial conditions of the current motion. The internal vector is used by the query() operation to calculate a snapshot state vector of the current motion. The timing object is said to be moving if the velocity and/or acceleration of its internal vector is non-zero. If the timing object is associated with a timing provider object, the internal vector is provided by the timing resource provider and therefore includes a timestamp value from the timeline of the timing resource provider.
+>>>>>>> 7243da8282da0b75a6504e779f98ff42a5e488b5
@@ -634,7 +646,11 @@
TimingObject whose timing provider source is provider.startPosition property.endPosition property.readyState property.readyState property and, if different from connecting, queue a task to fire a simple event named readystatechange at timing.vector property.skew property.skew property is observed, run the following substeps:
skew property is observed, the user agent MUST adjust timing's logical clock, gradually if necessary to preserve the monotonicity of the clock.
+>>>>>>> 7243da8282da0b75a6504e779f98ff42a5e488b5
This observing mechanism is meant to emulate the Object.observe method that is being proposed in EcmaScript 7 to simplify the TimingProvider interface and requirements set on a timing resource provider, as well as to work around the fact that TimingProvider cannot inherit EventTarget. The Multi-Device Timing Community Group welcomes feedback as to whether this approach is doable in practice.
+ Should the procedure detail how to apply skew changes gradually to preserve the monotonicity of the logical clock or should that rather be left as an implementation detail?
+
- The concept of timing provider is introduced in order to leave space open for innovation among online timing providers. The idea is that third parties may provide different implementations of timing provider objects in JavaScript, to which timing objects may be connected. So, the purpose of the timing provider mechanism is to decouple the user agent from any particular timing resource provider. In particular, this means that the protocols and logic used to identify, create or destroy an external timing resource, synchronize clocks and propagate state vectors to connected user agents, are up to the timing resource provider. Similarly, a timing resource provider may require Web applications or users to authenticate themselves before they grant them access to a particular timing resource. + The concept is introduced in order to leave space open for innovation among online timing providers. The purpose is to decouple the user agent from any particular timing resource provider: third parties may provide different implementations of timing provider objects in JavaScript, to which timing objects may be connected. In particular, this means that the protocols and logic used to identify, create or destroy an external timing resource, synchronize clocks and propagate state vectors to connected user agents, are up to the timing resource provider. Similarly, a timing resource provider may require Web applications or users to authenticate themselves before they grant them access to a particular timing resource.
In practice, a Web application willing to use a particular timing resource provider needs to load the corresponding JavaScript library provided by this timing resource provider, create a timing provider object and pass that object to the timing object constructor.
- The timing provider interface allows the timing object to exercise control over the timing provider object, as well as be notified of state changes as soon as they occur, in particular state vectors and clock skew estimates. As the clock of the timing object [[HR-TIME]] defines its own local timeline (on load) - timestamps must be translated between the timeline employed by the timing provider and [[HR-TIME]]. For this, an estimate of the skew between the two timelines is required. In the case of online timing resources this skew is a floating estimate (due to variance in network latency and relative clock drift over time). The query operation on the timing object should always be resolved using a fresh skew estimate received from the timing provider object. Skew is defined below;
-
- clocktiming provider = clockuser agent + skew
+ The skew specifies how timestamps may be translated between the timeline of the performance clock and that used by the timing resource provider. In the case of online timing resources, the skew is a floating estimate (due to variance in network latency and relative clock drift over time). The query operation on the timing object should always be resolved using a fresh skew estimate received from the timing provider object. Skew is defined by the following equation (where clockuser agent is the performance clock):
- As the timing provider object and the timing object do not execute in the same thread, timely notifications from the timing provider object to the timing object is achieved through the use of observable properties. + clocktiming provider = clockuser agent + skew
A timing provider object implements the following interface: @@ -953,7 +973,7 @@
- The update method sends a request to the timing resource to have it update the external timing resource, based on the provided state vector, and returns a Promise that the update was processed by the timing provider (see the update method of TimingObject objects for more details). When the method is invoked on a timing provider object provider, the timing resource provider MUST run the following steps:
+ The update method sends a request to the timing resource to have it update the external timing resource, based on the provided state vector, and returns a Promise that the update was processed by the timing resource provider (see the update method of TimingObject objects for more details). When the method is invoked on a timing provider object provider, the timing resource provider MUST run the following steps:
Promise.
- The TimingStateVector constructor is used by the timing resource provider to set the vector attribute of a TimingProvider object. It is also used as return value from the query() method of the timing object and as parmeter to the update of a timing provider object.
+ The TimingStateVector constructor is only intended to be used by the timing resource provider to set the vector attribute of a TimingProvider object.
When the TimingStateVector constructor is called, the user agent MUST run the following steps: