[JDEV] jabberd patch

[Richard Dobson]

> >But as ive just said in my previous email I dont think it actually
> >gets a stream error..
>
> Exodus tells me:
> <stream:error>Disconnected</stream:error></stream:stream>

Sure I know, it has already been pointed out, I just hadnt noticed this
before, but then I havent specifically been looking for it :)

> So we do get a stream:error... (and the presence changes to offline
> "[09:49:35] *** test556 at mordax.com is Offline [Replaced by new
> connection]" after wich it changes to online again when the new
> connection sends it's presence)
>
> 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.

> 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.

> 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.

> 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 ??

Richard