- From: Ingar Arntzen via GitHub <sysbot+gh@w3.org>
- Date: Wed, 24 Feb 2016 09:08:08 +0000
- To: public-webtiming@w3.org
ingararntzen has just created a new issue for https://github.com/webtiming/timingobject: == Matching change events to update requests == Updating the timing object involves the following steps. 1 an update request is created by the timing object and dispatched to the timing provider 2 the timing provider object processes the update request and (eventually) updates its vector as a result 3 the new vector is communicated back to the timing object 4 the timing object caches the new value and emits a vector change event Events in step 4) are emitted asynchronously, and for online timing providers step 1) and 4) may be separated in time by network RTT or more. Furthermore, events do not include any clues to their causal origin. This means that it is not possible for an application to recognize a particular change event as causally linked to an earlier update request. This is typically ok, but problematic in some specific cases. For instance, in interactive UI elements it may sometimes be desirable to apply changes locally immediately after step 1) to increase responsiveness. This strategy will require some additional bookkeeping to distinguish a speculative vector guesses from a vector confirmed by the timing provider. Furthermore, processing vector changes from the timing provider in 4) will either confirm a speculative guess, or falsify it. In the first case, the *change* event should be suppressed as it would be obsolete. A primitive version of such speculative behavior is implemented by the LocalConverter [1] Also related to [Issue 13](https://github.com/webtiming/timingobject/issues/13), several timing converters works by suppressing some events and/or spontaneously generating new events. This further illustrates the need for some concept of event origin, allowing timing objects, timing converters and application code to distinguish for example: - if event was caused by update request issued from *self* (i.e. timing object, converter or application) - if event was caused by update request issued from *child* (i.e. timing converter or application) - if event was spontaneously generated by *parent* (i.e. *timingsrc*) - if event was caused by update request issued from the same process (i.e. same local timing provider instance) For instance, I imagine that this could be solved by some scheme involving identifiers (e.g. counter, timestamp, nonce) private to each object. Each node in a chain would append a freshly generated identifier on the update request before passing it on (to timingsrc), and when corresponding *change* events trickle back up these identifiers would be popped off and compared to request history. In any case, I think the spec must specify a solution for this, or at least leave some design space for such solutions. [1] [http://webtiming.github.io/timingsrc/doc/api_timingconverter.html#localconverter](http://webtiming.github.io/timingsrc/doc/api_timingconverter.html#localconverter) Please view or discuss this issue at https://github.com/webtiming/timingobject/issues/20 using your GitHub account
Received on Wednesday, 24 February 2016 09:08:10 UTC