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

Create ThreadView to track threads in a room #825

Open
wants to merge 1 commit into
base: dev
Choose a base branch
from

Conversation

nvrWhere
Copy link
Collaborator

@nvrWhere nvrWhere commented Nov 2, 2024

This is some initial work to make supporting threads easier. As part of the thread spec the root event gets some aggregation in the unsigned of the root event. However this is not automatically sync when the thread is started or a new message is added so we can't just rely on it's presence.

This leaves us with 2 options:

  1. Update the root event from the server every time a thread is started or updated - this will have a delay and hit the server
  2. Track this info ourselves

This PR does number 2.

A new ThreadView is created which holds a list of Thread objects each representing the info for a single thread. As new events are added to the timeline each one is now checked to see if it is threaded and if so a Thread is either updated with the info as required or created if it is a previously unknown thread.

This is intentionally a very simple start, I intend at some point for it to contain it's own timeline but before we can do that we would have to decide how we want to manage having the same event in multiple timelines.

@KitsuneRal
Copy link
Member

I happen to have the answer to the question about having the same event in several timelines. We really should separate the concerns of storing events and referencing them. Each room should have its own storage of events (could be unique pointers because we rarely delete events atm, but we could also use shared pointers or Qt's shared data paradigm); any event container (state or timeline) would then simply refer to the event. Event ids are obvious keys for the hash map storage, to find them whenever they are mentioned in sync/history batches. That really is it. It cannot be implemented without breaking the API because Room::Timeline is exposed in the API; but that's certainly something achievable for 0.10 and shouldn't disrupt client code too much.

@nvrWhere
Copy link
Collaborator Author

nvrWhere commented Nov 2, 2024

I happen to have the answer to the question about having the same event in several timelines. We really should separate the concerns of storing events and referencing them. Each room should have its own storage of events (could be unique pointers because we rarely delete events atm, but we could also use shared pointers or Qt's shared data paradigm); any event container (state or timeline) would then simply refer to the event. Event ids are obvious keys for the hash map storage, to find them whenever they are mentioned in sync/history batches. That really is it. It cannot be implemented without breaking the API because Room::Timeline is exposed in the API; but that's certainly something achievable for 0.10 and shouldn't disrupt client code too much.

As it so happens this is exactly what I was thinking.

Copy link

sonarcloud bot commented Nov 2, 2024

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

Successfully merging this pull request may close these issues.

2 participants