On 2011-04-26, at 9:28 AM, Dave Cridland wrote: > On Tue Apr 26 17:22:37 2011, Curtis King wrote: >> On 2011-04-26, at 8:00 AM, Waqas Hussain wrote: >> > A session only gets its own unavailable presence, not >> > another session's. Doing it otherwise would break completely. >> So what happens when there are two live and valid sessions? Sounds like one >> won't see the other leave the room. > > Waqas is talking about nick-sharing cases, though.
I know what Waqas and Kev were talking about, it was very easy follow. What I was talking about and which Kim answered was the success case, where two clients are sharing the same nick and one sends an "unavailable". I think the xep could be clearer on sending presence update in nick sharing case instead of making it implementation defined. The xep should say, send presence only to the full jid joining or leaving the room if there are duplicate nicks for that same bare jid. It should look like just one session for that nick to all other participants in the room even if there more than one session. > > I think that only Prosody and (unreleased) versions of M-Link do this, but > the same issue would apply in any case - follow the sequence that Kev gave > (or various similar cases), and you end up with a client reconnecting quickly > enough to receive the unavailable presence signifiying that it's left the > room. > > The solution for this would be to give a unique identifier for the MUC > session in the "you have joined" message - possibly in lieu of the status > code we use to indicate your session now - and then it would no longer be > ambiguous. I agree, since the nick is no longer unique we should add something which is. ck
