element-hq
[Story] 🦀 Event cache storage
Description
- As a user
- I do not want the app to reload timeline content every time
- So that I enjoy a snappy app with timeline instantly displayed
This project is about to make the existing Event Cache API persistent. The event cache exists but it is a in-memory cache. We want it to be a on-disk cache.
Acceptance criteria
- Live timeline events are permanently cached
- This cache is reset in case of a gap in the timeline
- The room list pre-fills this cache with X last messages so that the timeline instantly displays when the user opens a room
- More to be discussed
Leads
- Tech: @Hywan
- Design: <GitHub id>
Size estimate
None
Dependencies
- None
Out of scope
- Preload the cache from the notification service
Open questions
### Questions
Subtasks
### Android
### iOS
### Rust
- [ ] https://github.com/matrix-org/matrix-rust-sdk/issues/3280
### Other
Sign-off
Android
- [ ] Design sign-off on completion
- [ ] QA sign-off on completion
- [ ] Product sign-off on completion
iOS
- [ ] Design sign-off on completion
- [ ] QA sign-off on completion
- [ ] Product sign-off on completion
This cache is reset in case of a gap in the timeline
Why? We get gaps pretty often, what's the goal of this feature?
The room list pre-fills this cache with X last messages so that the timeline instantly displays when the user opens a room
It has nothing to do with the event cache storage right? It's a sync requirement (which is already present).
The full issue that describes all the work is https://github.com/matrix-org/matrix-rust-sdk/issues/3280.
@Hywan we need to discuss this user story and the acceptance criteria when we will be on it. This issue is even not a user story more a tech stories. The Event Cache Storage work can probably be splitted into several user stories.
This cache is reset in case of a gap in the timeline
Why? We get gaps pretty often, what's the goal of this feature?
I would be happy to remove this acceptance criteria. The occurence of the reset depends on the rooms traffic. Legacy SDKs reset the timeline DB in this case. We tried in the android SDK to keep multiple chunks of continous timelime items in the DB. When 2 chunks intersected, we merged them together into a big one but it required too much effort to get it right. Instead, we now keep only one in EA, the "live" chunk.
It appeared it was enough in term of UX in legacy apps. Thanks to notifications that regularly make v2 /sync requests, there are not that much timeline gap in useful, not too active, rooms. It is going to be different with SSS.
The room list pre-fills this cache with X last messages so that the timeline instantly displays when the user opens a room
It has nothing to do with the event cache storage right? It's a sync requirement (which is already present).
We still have the problem in EX that if all the messages returned by the default sync limit are not displayable, there is no last message in the room list. Legacy apps run /messages in those rooms to find a displayable last message.