First draft of Timing Object proposal

Hi participants of the Multi-Device Timing CG,

To help bootstrap discussions within the Community Group, Ingar, Njål 
and myself started to draft a specification that defines a timing object:

  http://webtiming.github.io/timingobject/

Quoting from the abstract: "the timing object is a local object that may 
be used by Web clients to ensure precisely timed execution. If multiple 
time-sensitive components take direction from the same timing object, 
their behaviour will be precisely coordinated in time. Crucially, this 
is also the case in distributed settings. A central motivation for the 
timing object is that it may be connected to an online timing resource. 
This way, the local timing object is a gateway to precisely timed 
operations, both in single-device as well as multi-device scenarios."

The introduction describes the concepts in details.
Section 2 lists a number of use cases that the spec would enable, some 
of them taken from the list defined in the Web and TV Interest Group.

The normative details really start at section 6 with the definition of 
the TimingObject interface:

  http://webtiming.github.io/timingobject/#timing-object-1

We initially tried to design the TimingObject interface to be as close 
as possible to the HTML5 MediaElement interface but realized that:

- this would restrict the timing object to some extent. For instance, on 
media elements, currentTime is in seconds, whereas a timing object may 
represent motion along other types of axes, so position unit can be just 
about anything in practice.
- this would make it easier for developers to "break" things. For 
instance, assigning currentTime and playbackRate independently would 
probably make developers forget that they should rather call "update" 
when they want to change both properties at the same time, to avoid 
propagation conflicts in a multi-device session.

The current approach rather defines a more generic timing object. 
Mapping with media elements will be done afterwards.

This first draft does not address the association between a timing 
object and an online timing resource. The "src" attribute on the 
TimingObject interface is of course meant for that but that part has not 
yet been specified.

I'll try to write down some of the questions that arose while drafting 
the spec. In the meantime, I encourage you to have a look and send 
comments to the mailing-list or raise issues on GitHub:

  https://github.com/webtiming/timingobject/issues

Thanks,
Francois.

Received on Friday, 27 March 2015 15:08:17 UTC