Management of range restrictions

[ingararntzen]

Management of range restrictions basically means emitting an event at the exact time when a range restriction is violated (i.e. when timing object reaches endPosition). This could be the responsibility of the timing provider or it could be the responsibility of the timing object. Currently, the spec indicates that this should be the responsibility of the timing object - not the timing provider.

I think this division of responsibility is very good

• it simplifies implementation of timing providers
• timing object (and timing converters) needs to manage this anyway (end-to-end principle)

For the details, recall that the timing provider has three relevant properties

• .vector (position, velocity, acceleration, timestamp)
• .startPosition
• .endPosition

In the interest of simplicity, I'd like to suggest that within the timing provider the .vector is NOT restricted by its own range. In other words, the .vector may describe a motion that happens OUTSIDE its own range, and that would be perfectly ok.

This is simple (no consistency checking) and clear, it avoids making unnecessary assumptions about the behavior of the timing provider, and it is in line with the idea that the timing object takes full responsibility for managing range restrictions.

The implication for the timing object is that it will have to manage two different scenarios with ranges

• motion from INSIDE the range to OUTSIDE the range (range violation - stop motion)
• motion from OUTSIDE the range to INSIDE the range (start motion from range )

I've implemented this behavior in the RangeConverter.

As a subtle bonus this simplification is even beneficial for some use cases with distributed synchronization, removing some corner-case complications.

[tidoust]

That sounds all good to me. The user agent would have to manage the scenarios with ranges that you mention in any case, since it cannot trust the code of the timing provider.