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

[Story] 🦀 Event cache storage #2405

Open
1 task
manuroe opened this issue Apr 24, 2024 · 4 comments
Open
1 task

[Story] 🦀 Event cache storage #2405

manuroe opened this issue Apr 24, 2024 · 4 comments

Comments

@manuroe
Copy link
Member

manuroe commented Apr 24, 2024

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

Size estimate

None

Dependencies

  • None

Out of scope

  • Preload the cache from the notification service

Open questions

Questions

No tasks being tracked yet.

Subtasks

Android

No tasks being tracked yet.

iOS

No tasks being tracked yet.

Rust

Other

No tasks being tracked yet.

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
@Hywan
Copy link
Member

Hywan commented Apr 25, 2024

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).

@Hywan
Copy link
Member

Hywan commented Apr 25, 2024

The full issue that describes all the work is matrix-org/matrix-rust-sdk#3280.

@manuroe manuroe changed the title [Story] Event cache storage 🦀 [Story] Event cache storage Apr 26, 2024
@manuroe manuroe changed the title 🦀 [Story] Event cache storage [Story] 🦀 Event cache storage Apr 26, 2024
@manuroe
Copy link
Member Author

manuroe commented Oct 11, 2024

@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.

@Hywan
Copy link
Member

Hywan commented Oct 21, 2024

This cache is reest 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.

Right now, the event cache lives in memory, and it handles gaps pretty well. The persistent storage will just be a replica of what we have in memory, nothing fancy will be done here, just a 1:1 mapping.

We also want to use the event cache persistent storage to be able to provide search (text, media…). If we reset the storage frequently, we fail to provide these cool features.

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

No branches or pull requests

2 participants