Chaining (was: Re: Proposal to update the spec)

On 2015-07-09 12:03, Ingar Mæhlum Arntzen wrote:
[...]
>     Additional Proposal : Chaining
>
>
> In addition we would like to suggest that timing objects should support
> chaining. Chaining would mean that a timing object (child) could take
> another timing object (parent) as timing source.
>
>
> A child timing object would be useful for providing an alternative
> representation of the parent timing object. For instance if a parent
> timing object represents position/velocity in milliseconds, a child
> timing object could represent the same timing source in seconds, or
> perhaps beats per second or frame number, depending on what makes sense
> for a programmer or a specific timed component.
>
>
> Another important use case for this would be to “skew” a timing object
> so that it matches the timeline of some given media or timed data. For
> instance, this strategy would make it easy to play a video between
> [200,324], even if the video comes with an internal timeline of [0,124].
> The same is true for timed data (e.g. TextTracks). The ability to chain
> timing objects generally implies that re-indexing of the media is not
> necessary, as it is presumably easier to just skew the timing object.
>
>
> Chaining may also be used to support dynamic switching of timing
> objects, without requiring any changes to the TimingObject API. Chaining
> only requires that timing objects allow their reference to parent timing
> object to be reset, and that a new update event is generated for
> children, based on the new parent. This way, a large set of timed
> components can easily switch back and forth between a private and a
> publicly shared timing object.
>
>
> Finally, note that chaining also matches proposal 1), where the
> HTMLTimingObject essentially takes a TimingProvider object as parent
> timing source. Ideally, the TimingProvider interface would at least
> implement the TimingObject API.

I agree that a mechanism like that would be pretty useful. This matches 
some of the use cases that I had in mind as well.

Allow me to finish the updates for proposal 1) first (I hope to be done 
by tomorrow). We may want to keep a clean separation between a 
TimingProvider interface that should remain as simple as possible and 
the TimingObject that user agents will implement. In particular, I think 
we should limit the number of requirements we put on timing providers to 
a bare minimum, as we will have limited control on what they do in practice.

Although interfaces will be "compatible", I don't think that one 
interface can inherit from the other, given that one creates what 
[WebIDL] calls a platform object while the other creates a user object.

We could drop "srcObject", rather say that TimingObject has a 
"timingsrc" attribute (as media elements and TextTracks) of type 
TimingObject and add an optional TimingProvider to the TimingObject 
constructor that would create a TimingObject that wraps the provided 
TimingProvider object. Setting the "timingsrc" attribute on a timing 
object created from a timing provider object would be forbidden.

I can see a number of alternatives along similar lines. Nothing as clean 
as a simple attribute that would handle both situations, but at least 
something that can be spec'ed out ;)

Francois.

[WebIDL] https://heycam.github.io/webidl/#idl-objects

Received on Thursday, 9 July 2015 13:59:43 UTC