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

Storage for Thread/changes #4250

Open
chibenwa opened this issue Feb 5, 2021 · 1 comment
Open

Storage for Thread/changes #4250

chibenwa opened this issue Feb 5, 2021 · 1 comment

Comments

@chibenwa
Copy link
Member

chibenwa commented Feb 5, 2021

Implement a ThreadChangeRepository (API / memory / Cassandra)

@chibenwa chibenwa modified the milestone: Sprint 6 Feb 5, 2021
@chibenwa
Copy link
Member Author

chibenwa commented Feb 6, 2025

Speaking with Jarry from AERC today I realise storage for Thread/changes is not needed. We can easily implement this as off today!

Here is how:

GETTING state for threads -> get the state for email ;-)

When I ask for changes since thread state B
THEN I just list Email changes since that date
AND we aggregate the data

addedEmailIDs = union(emailState.added.id)
addedTHreadCandidates = addedEmailIDs.map(this::retrieveThread) // record Thread(id, emailIds)
addedTHread = addedTHreadCandidates.filter(_.emailIds all contained in  addedEmailIDs)


changedEmailIDs = union(emailState.added.id ++ emailState.removed.id ) // updated emails never impact threads
updatedThreads = changedEmailIDs.map(this::retrieveThread falback to threadId is messageId) - addedTHread

This will effectively return deleted threads as 'updated' but clients WILL be able to resynchronise this and detect the actual deletion through a Thread/get call.

Cc @quanhoang1408

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