Perhaps of interest here. I'm not yet convinced that this is a bug in the spec...
-------- Original Message -------- Subject: Re: [ejabberd] another mod_muc question: duplicate nicks from same user Date: Mon, 25 Apr 2011 16:46:07 -0400 From: Armando Di Cianno <[email protected]> Reply-To: [email protected] To: [email protected] On Mon, Apr 25, 2011 at 2:34 PM, Daniel Dormont <[email protected]> wrote: > My question is: does Ejabberd permit this? If so, does it have to be > enabled in the config somewhere? I have done some brief experiments > and it doesn't seem to work: instead the new joinee receives <error > code='409' type='cancel'><conflict > xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/><text > xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>That nickname is already > in use by another occupant</text></error> If it permits it by config, I do not know. However, I wanted to chime in. You've touched upon a /really/ interesting misfeature in the MUC XEP, imho. I recently had to battle solving a client's requirement to correctly handle quick disconnects and reconnects. If the server notices the client disconnect, it'll disconnect the "old" client session (normally, or via mod_ping), however, the user may have already reconnected. A misinformed client program will happily get the "unavailable" stanza from the server, and think that it's its own, as the client is processing the message as if it received it with the bare jid, not including the resource. From my tests, ejabberd on the server side, and libpurple/pidgin and adium are okay. I'd bet a few dollars that every other client or library in the world is doing it wrong. So, just that caveat: beware of relying on any behavior in this realm all too much ... at least not without a lot of further testing. __armando _______________________________________________ ejabberd mailing list [email protected] http://lists.jabber.ru/mailman/listinfo/ejabberd
smime.p7s
Description: S/MIME Cryptographic Signature
