> "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 :)
Ah but do those error cases you talk about create errors of "Disconnected" ?? > 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". But it doesnt just say error, it says and i quote: <stream:error>Disconnected</stream:error></stream:stream> Now AFAIK that error is only caused by other sessions causing the termination of an old session, so clients dont really have an excuse even now to not handle that, Exodus manages it why cant the rest. So as ive said any clients that exhibit the session fighting behaviour do have a bug and need to be fixed since there is a way to properly handle it. > 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. Yup proper error codes will help a lot, but at the moment the server does effectively tell you what has gone wrong and gives you a "Disconnected" error so clients dont really have any excuse not handling 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. Ah yes I was thinking about this option, that could solve the previous gentlemans problem with sessions being terminated without altering basic behaviours of the server for other clients. So maybe we need some kind of option introduced into the auth so the client can tell the server it doesnt want any existing sessions terminated if they exist, I think this is the best option to solve the problem for all parties involved. Richard _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
