From JEP-0045 the Change Nickname publishes two presences to all room occupants - first an unavailability with status 303, followed by a available presence. I’'m having difficulty differentiating the 2nd available presence from a Join Room presence, since the available packets are identical.
Any suggestions?
P.S. It seems to me that maybe 1 available packet with status 303 is sufficient to identify a nickname change… why two?
Hey stoopidboi,
Since your question is in fact related to the JEP I think that you may get more responses by posting it to http://mail.jabber.org/mailman/listinfo/standards-jig/. Anyway, my guess is that the JEP author tried to write a specification that doesn’'t break old/simple clients. Old or very simple clients may only understand available/unavailable presences. So in this case they would simply remove the old room occupant and add the new one. More advanced clients may not only do the latter but also display a message in the room window indicating that X is now known as Y.
Hope that helps.
Regards,
– Gato
OK, I now understand why 2 presences are used. In fact, I am trying to display that X is now known as Y, which I can achieve with the first of the 2 presences. However the 2nd presence showing up as joining the room. I’'d appreciate suggestions on how to handle the 2nd “change nickname” presence which I need to differentiate from a “join room” presence.
If someone is already online, he/she can’'t join the room.
btw, while playing around with muc today (testing my implementation against Spark), I discovered that spark has the same issue sometimes:
hal is now known as hal2
hal2 has joined the room.
hal2 is now known as hla
hla has joined the room.
hla is now known as hal
Strange I don’'t get it sometimes, I get it ALL the time! So its a SparkBug?
Perhaps once Spark fixes it I can learn how to do it then.