Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement reliable message caching #22

Open
nesium opened this issue Aug 18, 2023 · 0 comments
Open

Implement reliable message caching #22

nesium opened this issue Aug 18, 2023 · 0 comments

Comments

@nesium
Copy link
Contributor

nesium commented Aug 18, 2023

The goal is to minimize roundtrips to the server for messages that have been loaded already.

Some loose thoughts:

I believe that going back in the local message list and see which ones have an ArchiveID does not work reliably. There is no way to know which messages you may have missed. Even using Stream Management (XEP-0198) you only know earlier that you’re missing messages, well even how many in fact. But there’s also the scenario where the user could quit the app at any time when fetching missing messages (or a blackout). So that feature is basically only for reliably sending messages. You can cache sent messages in a local db until you receive a confirmation from the server that they have been received. Additionally the user could open the app hours/days/weeks later and loading the latest batch of messages could leave a hole between the latest and the last received ones. So you’d have unreliable data in the past locally.

My take is that the only guarantee is receiving a page from the server (MAM) with a count. You’d then know that at least between two message IDs you’d have all the messages in between. Thus the cache would need to be modelled around this concept (messages belonging to a page). Of course there would be some redundant loading until a page is full.

Relates to #21

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant