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
Proposal: have the spec specify that you only emit a leave event if a member was removed.
Presence events are only emitted by the SDK if they pass a 'newness check': RTP2g. The general idea is that presence is a CRDT, and you don't need to emit an event that does not change your local presence set state, only newer versions of the presence message for a particular member (which might container newer versions of the data).
That reasoning would also imply that we should only emit a leave event if a matching member was previously present in the local view of the presence set, else the leave does not cause a change in local state. But we don't currently do that. Why not? This feels like an obvious thing to do, I feel like I must be missing something?
The text was updated successfully, but these errors were encountered:
Would we be able to provide guarantees around which presence event would cause the emission?
For example, if a client explicitly leaves presence and immediately detaches (causing an implicit leave), is there a guarantee here that the explicit leave will always win-out? The implicit leave would have whatever data is currently in the presence set, which may be "outdated" compared to any data sent with leave. I can imagine a use-case where someone might depend on the leave data, which they won't get if the implicit wins. I believe the answer to the above is "yes", but wanted to double check!
Besides that, this seems like a reasonable proposal.
For example, if a client explicitly leaves presence and immediately detaches (causing an implicit leave), is there a guarantee here that the explicit leave will always win-out?
Realtime transports preserve order. So if you leave before sending a detach, then yes, the explicit leave should arrive first.
(That said, if someone's designed something that depends on the client being able to specify the data in the leave event, that's a bit of a design smell. Half the point of presence as a feature is that the service will leave on your behalf if you eg have internet issues and disconnect abruptly, and in those situations the client clearly can't control the leave data)
Proposal: have the spec specify that you only emit a leave event if a member was removed.
Presence events are only emitted by the SDK if they pass a 'newness check': RTP2g. The general idea is that presence is a CRDT, and you don't need to emit an event that does not change your local presence set state, only newer versions of the presence message for a particular member (which might container newer versions of the data).
That reasoning would also imply that we should only emit a leave event if a matching member was previously present in the local view of the presence set, else the leave does not cause a change in local state. But we don't currently do that. Why not? This feels like an obvious thing to do, I feel like I must be missing something?
The text was updated successfully, but these errors were encountered: