On Sat, Jan 22, 2011 at 2:16 AM, Peter Saint-Andre <[email protected]> wrote: > XEP-0045 now allows multiple full JIDs for the same bare JID to "share" > a single nick in the room. For example, both [email protected]/balcony > and [email protected]/chamber could join [email protected] > as [email protected]/JuliC. > > This introduces a possible point of confusion. When Juliet leaves the > room from her "balcony" resource, she will still be in the room with her > "chamber" resource. However, a client that receives unavailable presence > from [email protected]/JuliC might assume that JuliC is no > longer in the room. > > In a non-anonymous room we have a workaround, because the service sends > this: > > <presence > from='[email protected]/JuliC' > to='[email protected]/pda' > type='unavailable'> > <x xmlns='http://jabber.org/protocol/muc#user'> > <item affiliation='member' > jid='[email protected]/balcony' > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > role='none'/> > </x> > </presence> > > However, in a semi-anonymous room the service does not include the real > full JID of the entity that has departed. Therefore, I wonder if we need > to define a new status code that enables the service to indicate that > JuliC still has presence in the room. > > <presence > from='[email protected]/JuliC' > to='[email protected]/pda' > type='unavailable'> > <x xmlns='http://jabber.org/protocol/muc#user'> > <item affiliation='member' > role='none'/> > <status code='120'/> > </x> > </presence> > > (Yes, I know that we want to get rid of the status codes in favor of XML > elements, and I'll work on that soon...) > > Peter
In Prosody's implementation we don't broadcast an unavailable presence. That would confuse practically all existing clients. We do this: 1. Send an unavailable presence to just the full JID which is leaving 2. Send nothing to the other sessions in the same nick 3. If the session's leaving causes the nick's presence to change, we broadcast the nick's new presence to everyone except that nick We have one or more sessions per nick. Each session has a presence. One of these sessions is chosen, and its presence becomes the nick's presence. A session always sees its nick as having its own session's presence. All other nicks see the nick's presence. There's a lot to think about in multi-session nicks. Joins, leaves, nick change, private messages and IQs, etc. In our implementation our focus has been on flawlessly supporting existing clients. -- Waqas Hussain
