jgaehring
commented
4 years ago I've also created a new label for "caching" issues, because I think these should be addressed together. Particularly #285 and #349 seem to be more a matter of what logs get stored locally, and how they're removed or not when they're no longer needed. Contrast this with the similar issue of what logs get displayed, and which logs don't, which also seems bound up in issues #285 and #349. I think the issue of what to display cannot be addressed until we have refined the use cases for My Logs and split it up into smaller, more targeted modules (#243). For instance, the rules governing what logs should be displayed for an Observation module are very different from what should be displayed for a To-Do module. If we give the individual modules the decision over what to display or not, but the underlying, global caching strategy will remain the same, then we've properly separated the caching issues from the display issues, and I think can then deal with them more appropriately.
I was talking the other day with @paul121 about making it more flexible for Field Modules to request, sync and store their own data, and I'd really like to explore this more.
I'm thinking now that our current strategy, where each Field Module provides a
filtersobject as a part of itsmodule.config.jsfile, is a bit too rigid. I think some of the difficulty I've experienced with #342 is a testament to how impractical that model was. I realize that my main concern wasn't so much with syncing, as it was with caching, and specifically the possibility of caching the same log twice. However, I believe that risk has been eliminated by the new method we're using for generating thelocalID.I'm also thinking about issues like purging logs (#285) and how they could be avoided if we just had a simple strategy for what logs we cache. In that issue @mstenta uses the comparison to the Gmail app on your phone, which keeps 30 days of emails synced by default, with the option to change it in the settings. We'd probably want something like the past 30 days plus the next 30 days, since we have future-dated logs (unlike email).
Generally though, I think it would be pretty simple to have a global setting such as this, strictly for caching. Then we could provide some kind of common interface for Field Modules to be able to request whatever logs they needed. Whichever of those logs fit the global caching criteria would be cached, and which ever didn't wouldn't. If the device didn't have a network connection when that request was made, that same interface would have a fallback method to check the cache for any logs that met the criteria. This would get a little complicated when it came to merging changes and all from the server, but I think it could be managed. It would also give us a clear strategy for removing logs from the cache as time progressed.
I think, down the line, we could maybe provide Field Modules with the option to extend the global caching limit, like if it really relied on having all seeding logs for the whole year or something, available at all times, but that's a bridge we could cross when we get there.