You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a sticky topic and I am proposing one possible solution. This is by no means the best or the final.
Groups can be synchronized independently from each other. In ideal conditions, all groups will have exactly the same cursor, which is the same "last_seen" as the one used by the main stream.
Upon restart or reconnect, a new stream can be opened with exactly the same last_seen as last time and no messages will get missed.
Realistically this might not work in the real world in all cases.
We have been talking about clients that have 1000s of groups or clients who's network capacity can't keep up with the message stream.
It is feasible to assume that the client might want to sync the most important (or last seen, or most recently messaged) groups first and then batch the remaining 1000s in some slower pipe.
Solutions like these would lead to a world in which each group has a different last_seen cursor.
At a bare minimum, this feature is required for #1544 / #1543
Describe the solution to the problem
No response
Describe the uses cases for the feature
No response
Additional details
No response
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem?
This is a sticky topic and I am proposing one possible solution. This is by no means the best or the final.
Groups can be synchronized independently from each other. In ideal conditions, all groups will have exactly the same cursor, which is the same "last_seen" as the one used by the main stream.
Upon restart or reconnect, a new stream can be opened with exactly the same last_seen as last time and no messages will get missed.
Realistically this might not work in the real world in all cases.
We have been talking about clients that have 1000s of groups or clients who's network capacity can't keep up with the message stream.
It is feasible to assume that the client might want to sync the most important (or last seen, or most recently messaged) groups first and then batch the remaining 1000s in some slower pipe.
Solutions like these would lead to a world in which each group has a different last_seen cursor.
At a bare minimum, this feature is required for #1544 / #1543
Describe the solution to the problem
No response
Describe the uses cases for the feature
No response
Additional details
No response
The text was updated successfully, but these errors were encountered: