[timingobject] Management of range restrictions

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

== Management of range restrictions ==
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.   

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

Received on Tuesday, 23 February 2016 14:14:32 UTC