[JDEV] jabberd patch

[Tijl Houtbeckers]

"Richard Dobson" <richard at dobson-i.net> wrote on 26-2-2003 12:46:48:
>
>> I still think this is questionable behaviour because there isn't 
>> really an error as such in the stream. I think there's been some 
>> discussion (amongst other things) on the XMPPWG list about adding 
>> other things as <stream:error> such as <stream:redirect>, and/or 
>> introducing errorcodes to the stream:error elemenent. (my guess is 
>> that it would be 409 in this case?). I don't subscribe to it so I 
>> don't know the outcome of this so far.
>
>Well I think it is perfectly valid to have it as an error, as the same
>argument about it not really being an error applies to 302 redirect 
>and that is will be an error code just as it is an error code in HTTP.

HTTP errors start with 4 and 5 if I'm not mistaken. (or do you consider 
2xx also an error code?) For the sake of the discussion let's assume it 
is an error though. You build up a connection, do a request and the 
server tells you it can't find the document at the place you specified 
but that it has moved to a different location. 

Now compare this to our situation. An event completly seperate from our 
own stream causes *our* stream to closed with a <stream:error/>. So 
comparing with HTTP won't do this situation any good. Let's instead 
look at the jabber.org documentation. 

"
Stream Errors

Errors may occur at the level of the stream. Examples include the 
sending of invalid XML, the shutdown of a host, an internal server 
error such as the shutdown of a session manager, and an attempt by a 
node to authenticate as the same resource that is currently connected. 
" 

"At the level of the stream" sounds pretty vague to me, but thankfully 
after that the example we're talking about is given. (Actually is sais 
"an attempt" to authenticate rather then "a succesfull attempt" even ;).
 But look at the other examples given.. shutdowns.. internal errors. In 
 those cases I would want my client to reconnect till the server is up 
 again. You can tell me that this makes me a bad person/client but I'm 
 not gonna press the "connect" button 20 times a minute just cause of 
 that opinion :) 

>> I don't think it's valid to say that a client shouldn't reconnect 
>> when it gets a stream:error, since you don't know what went wrong!
>
>Im sorry but I must strongly disagree with you on this point, IMO
>auto-reconnects should only happen when there are network problems that
>cause the socket to be disconnected or drop in which case no stream 
>errors would get received. But I do agree that the errors should be 
>more specific, i.e. error codes as being discussed at the moment. 
>Although at the moment the only cause of a "Disconnected" error I can 
>think of is where a new session has logged in terminating the old one 
>(does anyone know of any other cases where this error can occur???), 
>so at the moment client authors should be handling that error and not 
>trying to re-connect automatically if they dont they need to be fixed 
>end of story. 

As you can see in the documentation (and this does happen in the real 
world too) there are more cases in wich this can happen. It's not wise 
to tell clients to cripple themselves because we have a protocol 
problem. Rather, let's fix the protocol problem and *then* bug the 
client authors till they update it. 

I want my client to reconnect unless the server tells it there is a 
good reason not to. Right now it does not, it's just sais there is an 
"error". 

>> Anyway, since Wes Morgan demonstrated a use for this, I still think
>> there should be a standard way to deny clients who try to log in with
>> the same resource as well. Perhaps the same (409) errorcode? (And I'm
>> *still* not saying that this should be standard behaviour).
>
>Yea thats fine that their could possibly be the "option" where a 
>particular application may require it, but it must not be default or 
>standard and should not be used where normal clients are connecting 
>especially where you have novice users.

I agree with you that the "normal behaviour" regarding logging in with 
the same resource should not be changed. There should be proper "error"-
codes or alternate elements for closing the stream though. Also it's 
not a bad idea for clients to expect the possiblity of a "409" when 
logging in on a server that has this enabled.. though it's unlikely to 
happen (any time soon) it won't make them worse clients for having it. 

Another alternative would be letting the client(s) decide wether they 
want to take over an excisting session (or whether they want to allow 
this). If we have proper error-codes for this such a system could 
always be created later on without breaking or confusing excisting 
clients. 

>> As far as I remember some other types of connections (with no 
>> resources tied to it) experiance even stranger behaviour (for example
>> component:accept), when I open a second connection it just sends
>> everything back over the first after authentication (At least I think
>> it did.. it's been a while ago..). I'm not suggesting we copy this
>> behaviour though :)
>
>Well that seems to be an implementation issue rather than a protocol 
>issue to me, and since component connect protocols are not really 
>standardised and are much more implementation specific im not sure how 
>it applies to the current discussion ??

Just a reminder that things aren't necisarly always best the way they 
are currently implemented... or it might intrested some other people.. 
I dunno! :) 

-- 
Tijl Houtbeckers
Software Engineer @ Splendo
The Netherlands