Re: [timingobject] Matching change events to update requests (#20)

Hi Christoph. 

Yes, you are right, this is certainly possible. But it implies that application programmers must recognize and ignore change events from own updates, in order to avoid duplicate calls to updateUI() related to the same button click.

It would be possible to include this functionality into the timing object. For instance, the timing object could optimistically process the vector change locally, and emit the change event immediately, resolve the update promise, and also forward the new vector as a request to the timing provider. This way, application programmers could handle all change events the same way, which is very practical. This would also imply that there would be no extra update latency for online timing objects, compared to local ones.

However, this approach has implication for consistency and complexity.
1. With updates being optimistically applied in the update interface, it will show here before it shows in other interfaces. This though, may well be quite acceptable in many application. But there could be some applications where this is not wanted, which maybe suggest that there could be a _mode_ to set the appropriate behavior
2. Optimistic update processing implies more complexity for the online case. For instance, if an update requires times out, for instance if the online timing provider is temporarily disconnected, then the optimistic update must either be rolled back or retried when the timing provider reconnects.

The specification draft and the timingsrc library does not currently support optimistic updates. This was because it was the simplest solution at the time. I think it the ideal solution would be for timing objects to do optimistic updates by default, with an option to turn it off when not needed. 



-- 
GitHub Notification of comment by ingararntzen
Please view or discuss this issue at https://github.com/webtiming/timingobject/issues/20#issuecomment-1464880830 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Saturday, 11 March 2023 10:30:09 UTC