I don't know if this will help, but as it happens I was the originator of this thread on ejabberd so I thought I'd speak up. I'm also a bit new to all this :)
The specific use case in my scenario involved BOSH connections, in which case it is quite realistic that one client will lose a connection, regain it (but usually with a new resource string) and have the server think the old session is still connected for some time. Truthfully, what I'd really love to be able to do here is not share the Nick at all, but have the new session *replace* the old one as the owner of that nick in that particular MUC. I could see the idea of stealing nicks being undesirable in general, but perhaps it should be allowed if the bare JID is the same? I realize Armando's message below is talking about a more subtle and more specific problem, so forgive me if this is out of place. Dan On Mon, Apr 25, 2011 at 4:50 PM, 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 > >
