- From: Ingar Arntzen via GitHub <sysbot+gh@w3.org>
- Date: Tue, 23 Feb 2016 14:14:30 +0000
- To: public-webtiming@w3.org
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