Confirmed users
471
edits
Identity/CryptoIdeas/05-Queue-Sync: Difference between revisions
m
more reshuffling
m (rearrange sections) |
m (more reshuffling) |
||
| Line 173: | Line 173: | ||
The easiest option may simply be to respond to any re-sync -time conflict by restarting the whole re-sync operation. | The easiest option may simply be to respond to any re-sync -time conflict by restarting the whole re-sync operation. | ||
= Upstream Change Delivery = | |||
new build-number calculation, hash-chain calculation, ACK/NACK. | |||
= Downstream Change Application = | = Downstream Change Application = | ||
race detection and merge, scanning/modifying the upstream queue. Filtering downstream changes from the upstream observer. | race detection and merge, scanning/modifying the upstream queue. Filtering downstream changes from the upstream observer. | ||
= Downstream Cache = | = Downstream Cache = | ||
For simplicity (in particular to decouple transactionality between the native datastore and the downstream queue), we may have the browser perform a "resync" at every boot. To avoid re-fetching the entire server dataset each time, we can maintain a full copy of the server's dataset in a "Downstream Cache". This is updated when we receive downstream changes, with a transaction that simultaneously updates the cached data and the new build number. With this, we can safely request only new changes each time. In the ideal case (where nothing has changed on the server), a single roundtrip (returning or confirming the current build number) is enough to make sure we're up-to-date. | For simplicity (in particular to decouple transactionality between the native datastore and the downstream queue), we may have the browser perform a "resync" at every boot. To avoid re-fetching the entire server dataset each time, we can maintain a full copy of the server's dataset in a "Downstream Cache". This is updated when we receive downstream changes, with a transaction that simultaneously updates the cached data and the new build number. With this, we can safely request only new changes each time. In the ideal case (where nothing has changed on the server), a single roundtrip (returning or confirming the current build number) is enough to make sure we're up-to-date. | ||