Multiple timing objects from same (online) timing provider

[ingararntzen]

The spec defines a 1:1 relationship between a timing provider and a timing object. The timing provider is a very small thing, essentially:

• 1 skew
• 1 vector

The timing object wraps this to provide some additional logic and an API.

In practice though, applications might well require more than one timing object. For example, a multi-device slide show may use one timing object to control the progression of the slide show, and other timing objects to control media within each slide. Furthermore, in the online scenario it may be practical that these timing objects are hosted by the same online timing provider. This would provide opportunity to multiplex the communication of multiple timing objects across a single connection, and it would also enable the sharing of timing provider clock - see #22.

Especially, with respect to clock sharing the current spec is a bit inconvenient. The 1:1 relationship dictates that each timing object independently has to receive skew updates and maintain a timing provider clock internally. This is redundant if timing objects are connected to the same online timing provider.

To fix this, a basic idea would be to redefine the timing provider so that it includes

• 1 skew
• N named vectors

This would have some implications for the constructions and of timing objects.

For example:

var tp; // timing provider
var to = new TimingObject({provider:tp, name:"nameofvector"});

This would require the TimingObject internals to maintain one static, singleton clock (#22) per unique timing provider, and route skew updates there intstead of to the timing objects.