Re: [timingobject] The query() method should enforce range restrictions on position

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. 


-- 
GitHub Notif of comment by ingararntzen
See 
https://github.com/webtiming/timingobject/issues/11#issuecomment-133898036

Received on Sunday, 23 August 2015 18:59:45 UTC