Open sboesen opened 1 year ago
By the manifest file, do you mean the plugin's manifest on the remote service?
Just by my understanding, doesn't the manifest only change when the plugin is updated (version number). Wouldn't we want to check data.json, since that modifies every time we sync? And also, if we are checking for remote changes, wouldn't the .obsidian folder have to be synced, what about with syncing .obsidian is disabled?
I've probably misunderstood since I don't entirely know how the syncing process works. If we are checking the plugin's local files then those won't update until they are synced right, so wouldn't you have to check on the remote service?
We call the manifest both manifest.json, where you're right, and the manifest which is stored encrypted containing the list of deleted files. This is uploaded on first sync and currently used to determine if the user has unencrypted files (in addition to not setting a password).
Definitely confusing using the term for both
Ahh that makes so much more sense. So I'm assuming the manifest file is modified on sync?
This manifest modified check would be cheaper than a full sync.
Sounds like a good idea, are there any drawbacks to accessing it on the remote service routinely?
Can't be worse than doing a full sync every few seconds! I think we can modify auto sync to use this behavior, and sync on save to stay the same.
So I'm assuming the manifest file is modified on sync?
Yes but might need to change the plugin so it isn't modified if there is nothing to sync. Not sure.
Can't be worse than doing a full sync every few seconds! I think we can modify auto sync to use this behavior, and sync on save to stay the same.
That's true.
I think we can modify auto sync to use this behavior
I think that would be great, might also want to make a legacy version of the auto sync though for people who want to be extra sure. Personally I'd just rely on auto sync and sync on save.
Yes but might need to change the plugin so it isn't modified if there is nothing to sync. Not sure.
We could actually combine some of this behaviour with #43. We will need to track sync history so a SyncHistory.json or similar could serve a double purpose. With the date and (success/error) added on each sync. In the case people don't want sync history then it can just overwrite the first item and I think it will still be marked as modified. 🤔
Does each cloud service support checking modification times? If not we might have to make a standard way of checking. Could always download a really small file but not sure if that would really be light weight each second or so.
This should probably be done in conjunction with fixing how deleted files are managed.
I think most providers do, worth confirming before going too deep on implementation though.
Thanks to @kadisonm this should be fixed in 0.4.33!
What feature are you suggesting?
See comment.
We could cheaply (energy/network usage) check if the modification time for the manifest file is later than our last sync, and if so, check for a sync. This manifest modified check would be cheaper than a full sync.
Not sure I'll implement this, but more of a brainstorming issue.
What remote cloud services are you using, or suggesting adding the feature to?
No response
Ensure no sensitive information