Skip to content

Optimize marking views as read/unread using the most efficient server endpoint for our state #652

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

Open
timabbott opened this issue May 8, 2024 · 1 comment
Labels
a-api Implementing specific parts of the Zulip server API

Comments

@timabbott
Copy link
Member

Similar to zulip/zulip#29521, we can choose between the two different valid ways to ask the server to mark a given view as unread based on whether we can prove a smallish number of message IDs that we have cached is complete or not.

@timabbott timabbott added the a-api Implementing specific parts of the Zulip server API label May 8, 2024
@gnprice
Copy link
Member

gnprice commented May 8, 2024

Thanks!

Chat thread with a bit more context. This should mean a noticeable speedup when marking a conversation (other than a very long one) as read or unread.

We don't currently offer marking as unread — that's tracked as #131. The biggest value for this optimization is in marking as unread, because the speed of marking as read is invisible to the user: it's one of the few places where the Zulip clients show a change immediately rather than waiting for the server to confirm it. So this will be most useful after #131.

@gnprice gnprice modified the milestones: Launch, B2: Summer 2024 May 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a-api Implementing specific parts of the Zulip server API
Projects
Status: No status
Development

No branches or pull requests

2 participants