On Tue, Apr 26, 2011 at 1:50 AM, Peter Saint-Andre <[email protected]> wrote: > 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 > >
I'm not clear on what's being said here. I'm guessing the assumption is the unavailable presence of one session in a nick goes to all sessions for the nick? If so, that's not true in e.g., Prosody's implementation. A session only gets its own unavailable presence, not another session's. Doing it otherwise would break completely. -- Waqas Hussain
