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

I made a `TimingProvider` implementation which essentially treats every update as an optimistic update. It doesn't necessarily use a central server as the source of truths. Therefore there is also no straightforward way to know when an update is done.

From the perspective of a single client the update is done when it is applied locally and sent out to all other clients. It's a synchronous process.

In case of concurrent updates there is a mechanism to reach consensus which will eventually update all devices with the same vector which means it is possible that an update to the vector gets overturned by another client at some point.
 
However I think the same could also happen with a central server. Let's say Alice updates the vector. The update was successful and got accepted by the central server. However Bob also makes an update which arrives 1ms after the update from Alice. Now the update from Bob gets accepted as well. Consequently Alice gets a notification with the new vector, too.

Technically the update from Alice got applied successfully but I would argue that there is not much difference to the system without a central server in practice. The result is the same. The update from Alice got overturned.

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


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

Received on Sunday, 12 March 2023 20:24:12 UTC