[timingobject] Multiple timing objects from same (online) timing provider

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

== Multiple timing objects from same (online) timing provider ==
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:

```js
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.


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

Received on Monday, 29 February 2016 10:18:08 UTC