[JDEV] jabberd patch

David 'TheRaven' Chisnall theraven at sucs.org
Tue Feb 25 05:42:16 CST 2003


I can see that this would cause problems in the case that a client died 
in such a way that the socket stayed open (not entirely uncimmon on 
X11).  In this case the user would be unable to reconnect without 
changing resource name, while at the moment they could just kick their 
old connection off by reconnecting.  On the other hand, this may still 
have uses, and since it's an option I see no reason why it shouldn't be 
included, as long as admins know only to enable it if they really need 
this behaviour.

Richard Dobson wrote:

>But remember as already noted doing it around that way introduces problems
>for the end user especially the novice user.
>
>----- Original Message -----
>From: "Wes Morgan" <wesm at libretech.org>
>To: <jdev at jabber.org>
>Sent: Monday, February 24, 2003 10:10 PM
>Subject: [JDEV] jabberd patch
>
>
>  
>
>>Attached is a patch file for jsm/authreg.c that enables one to alter the
>>behavior of jabberd 1.4 when someone logs in with a username/resource
>>combination that already has an active session. Currently the existing
>>session is kicked and the new one logs in. With this patch, one can add
>>    
>>
>the
>  
>
>><first-session-priority/> tag to the jsm section of jabber.xml and the
>>behavior is reversed. That is, the first session is allowed to continue
>>    
>>
>and
>  
>
>>the second one is not allowed to log in. I would appreciate comments on
>>    
>>
>this
>  
>
>>implementation. It may well be that there are better ways to do this. One
>>    
>>
>bug
>  
>
>>that seems to exist in this version is that the second client is not
>>    
>>
>informed
>  
>
>>of the login failure, but instead just sits there until it times out. I'm
>>    
>>
>not
>  
>
>>quite sure how to correct that. Thanks.
>>
>>Wes Morgan
>>    
>>
>
>_______________________________________________
>jdev mailing list
>jdev at jabber.org
>http://mailman.jabber.org/listinfo/jdev
>
>  
>





More information about the JDev mailing list