self-hosted/joplin
1
0
Fork 0
mirror of https://github.com/laurent22/joplin.git synced 2024-11-27 08:21:03 +02:00
Code Issues Releases Activity

Doc: Added link to new specs, and added more details to delta sync spec

Browse Source
This commit is contained in:
Laurent Cozic 2021-01-01 13:25:05 +00:00
parent f9fb1b8a81
commit d58f39823a
2 changed files with 21 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
README.md
View File

@ -109,6 +109,8 @@ The Web Clipper is a browser extension that allows you to save web pages and scr
- [Sync Lock spec](https://github.com/laurent22/joplin/blob/dev/readme/spec/sync_lock.md)
- [Plugin Architecture spec](https://github.com/laurent22/joplin/blob/dev/readme/spec/plugins.md)
- [Search Sorting spec](https://github.com/laurent22/joplin/blob/dev/readme/spec/search_sorting.md)
- [Server: File URL Format](https://github.com/laurent22/joplin/blob/dev/readme/spec/server_file_url_format.md)
- [Server: Delta Sync](https://github.com/laurent22/joplin/blob/dev/readme/spec/server_delta_sync.md)
- Google Summer of Code 2020

21
readme/spec/server_delta_sync.md
View File

@ -41,8 +41,25 @@ This is a known issue and to solve it would require looking ahead in event pages
## ResyncRequired error
In some cases, in particular when a delta cursor has expired, the server might throw an error with a "resyncRequired" error code. In that case, the client should discard their cursor and sync the complete data again from the beginning.
In some cases, in particular when a delta cursor has expired or is invalid, the server might throw an error with a "resyncRequired" error code. In that case, the client should discard their cursor and sync the complete data again from the beginning.
This error should be rare - currently it would only happen if the cursor is invalid. Later on, it will also happen when old events have been deleted after x months. So a client that has not synced in a long time might see this error. The error code could also be used to solve server-side errors in some rare cases.
When syncing from the start, there will be many "create" events for files that are already there locally. In that case, they should just be skipped.
When syncing from the start, there will be many "create" events for files that are already there locally. In that case, they should just be skipped.
## Regarding the deletion of old change events
Keeping all change events permanently would represent a lot of data, however it might be necessary. Without it, it won't be possible for a client to know what file has been deleted and thus a client that has not synced for a long time will keep its files permanently.
So most likely we'll always keep the change events. However, we could compress the old ones to just "create" and "delete" events. All "update" events are not needed. And for a file that has been deleted, we don't need to keep the "create" event.
The client would then follow this logic:
- For "create" events:
- If the file is present locally, update it with the version from the server.
- If the file is not present, create it using the version from the server.
- For "delete" events:
- If the file is present, delete it.
- If it is not, skip the event (not an error).
It might seem we could derive the "create" events simply by looking at the files in the directory - all files that are there would implicitely have a "create" event. The issue however is that it's not possible to reliably iterate over the files in a folder, because they might change in the meantime. The change events on the other hand provide an ID that can be used reliably to iterate over changes, and to resume at any time.