ingararntzen
commented
9 years ago Yes - query should enforce range restrictions. The query algorithm in the spec must be revised to include this.
Here's my intuition about this:
If a query is processed right after position crossed the range limit, but before the situation have been corrected by a "change" event (either triggered by timeout or event from timing provider), then I think the query processing should correct the situation by performing the update before returning. This would include generating the missing "change" event and appending it to the task queue. Also, make sure the timestamp returned by the query is equal or later than the timestamp of the update operation. Also, make sure to avoid duplicate events by dropping delayed events coming in a little later.
I'm not too concerned about the timing object being inconsistent with the timing provider for a small time interval. The alternative would be to not perform the change operation - but return query results that would be inconsistent either with the range or with the latest "change" event. I think it is more important that applications see a consistent behavior from the timing object.
Broadening the discussion a bit: In the distributed scenario [***] "change" events will always be a little late when they are delivered by the timing provider. A consequence of this is that, the "story" told by the timing object locally always risks being inconsistent with the timing provider for a short while, just after online timing resource processed the update, but before this information has reached the client. (See paper on Media State Vectors.)
[***] This might actually be true also in a single-device scenario - but on a smaller and less significant time-scale)
For example, consider an online timing resource that is approaching its range limit. However, 1 ms before the range violation is about to occur, it is cancelled by an incoming update that negates the velocity of the timing resource. However, due to network latency a client-side timing object may not learn about this cancelling until say 100 ms after the range violation should have occurred. In this scenario I think it is ok that the timing object inserts a range-violation update locally, even if no such update exists in the event history of the online timing provider.
In my view, such brief inconsistencies between timing provider and timing object is a natural consequence of the model, and we should not attempt to hide it. Instead we should make sure applications see a consistent behavior from the timing object.
When a TimingObject specifies a range, the
querymethod should enforce it and never return a position outside of that range, no matter whether the range is managed by the user agent or handled by some timing provider.Even when the range is managed locally by the user agent, a call to
querycould occur right after the position crossed a range limit but still before the user agent had time to update the internal vector, so throwing an exception seems a wrong approach here.Instead, the spec should rather mandate that the user agent return a vector whose position is at the range limit and whose velocity and acceleration are 0.
When the range is managed by the user agent, a
timeupdateevent will be fired shortly after. If the range is managed by a timing provider, it will depend on whether this timing provider does its job correctly or not. I don't think we should require the user agent to trigger the update and/or thetimeupdateevent on its own, since that would break the internal synchronization between the TimingObject and the TimingProvider object. If this creates weird situations in practice, we could perhaps say that the user agent may switch the TimingObject to an error state if the timing provider fails to enforce the range within a few seconds.