RFC: only emit a leave if there was an existing member #211
Comments
|
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. |
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) |
|
This was discussed in the RTF and agreed, I will turn this into a spec pr |
…ng member per #211 The actual behaviour change here is small (only whether non-sync leaves where there is no matching member currently present should emit a leave event), but I found the current structure of this spec section quite confusing (why are broadcast and members-map add/remove requirements defined separately, despite having the same requirements?), so ended up rewriting it. (Without deprecating the old spec items since this isn't actually a behaviour change except in that one case)
…ng member per #211 The actual behaviour change here is small (only whether non-sync leaves where there is no matching member currently present should emit a leave event), but I found the current structure of this spec section quite confusing (why are broadcast and members-map add/remove requirements defined separately, despite having the same requirements?), so ended up rewriting it. (Without deprecating the old spec items since this isn't actually a behaviour change except in that one case)
…ng member per #211 The actual behaviour change here is small (only whether non-sync leaves where there is no matching member currently present should emit a leave event), but I found the current structure of this spec section quite confusing (why are broadcast and members-map add/remove requirements defined separately, despite having the same requirements?), so ended up rewriting it. (Without deprecating the old spec items since this isn't actually a behaviour change except in that one case)
…ng member per #211 The actual behaviour change here is small (only whether non-sync leaves where there is no matching member currently present should emit a leave event), but I found the current structure of this spec section quite confusing (why are broadcast and members-map add/remove requirements defined separately, despite having the same requirements?), so ended up rewriting it. (Without deprecating the old spec items since this isn't actually a behaviour change except in that one case)
…ng member per #211 The actual behaviour change here is small (only whether non-sync leaves where there is no matching member currently present should emit a leave event), but I found the current structure of this spec section quite confusing (why are broadcast and members-map add/remove requirements defined separately, despite having the same requirements?), so ended up rewriting it. (Without deprecating the old spec items since this isn't actually a behaviour change except in that one case)
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: