[JDEV] jabberd patch

[Richard Dobson]

> If you want to put a hack in your client that's fine by me but it
> doesn't mean other clients are obligated to. IMHO it's the protocol and
> the server that are misbehaving since they kick the client without
> giving any reason.

Yes the server does not give the specific reason but it does tell you
something big has happened and clients should not be ignoring that and just
trying to reconnect IMO, until the error codes are implemented in those
cases human intervention should be needed to get the client to reconnect, in
most cases such errors will happen very infrequently unless something is
badly wrong at the server end or the client end (e.g. sending invalid xml)
so I cant really see what you problem is.

> So you can choose between a few options here:
> 1. accept the protocol is broken and not implement reconnect, thus
> compromising on the functionality of your client (some people will
> switch to clients with a different client if they can) 2. Introduce a
> bad hack to solve this bug in some cases. Compromises functionality in
> some other cases. 3. Leave things as they, accept the *protocol* is
> flawed and should be fixed. The more the problem will occur the faster
> it will be fixed properly and the sooner serveradmins will upgrade.
> Don't compromise on functionality because the error is in the protocol
> and servers.
>
> As you can see I prefer 3. You can choose 1 or 2 if you want, but you
> can't acuse developers who choose 3 of misbehaving.

It is not bad IMO and helps stop it in most cases and will help promote
updates for reasons I will detail later in this email. Also the protocol is
already being fixed/enhanced with error codes.

> >Ah but hopefully we can get the stream error codes into jabberd2
> >before it goes final so they can be used to reliably determine the
> >reason for disconnection.
>
> I hope so too.. there has been discussion on the XMPPWG but I haven't
> read the outcome, if any (do the mailinglist archives have a search
> function yet?)

IMO it seems to be reaching concensus.

> I really still don't think you should solve problems by introducing
> hacks into the client. If we fix the protocol, and then upgrade the
> clients *properly* this will only be a good stimulation for those
> thousands of servers to upgrade. If we introduce a hack servers are
> less likely to upgrade and clients less likely to implement a proper
> fix because it already works "properly" in a large part of all cases.
> This way the hack will become "semi-offical" and we all know what kind
> of problems that brings along.

I dont consider it a hack and fixing the protocol is already in progress.
Also since just using the stream:error as Exodus does will stop
auto-reconnecting in the cases you mention were it might still want to try
auto-reconnecting I would argue that it would be a source of stimulation for
the server devs to update their servers to support error codes, and it would
be stimulation for client devs too.

> This is exactly the kind of thinking I'm opposing here. Just because a
> (very) large part of the servers supports your hack that's a reason to
> go ahead with it? This is what incompatabilities are made of! It goes
> directly agains the thinking behind open standards because it corrupts
> them.

BTW it is not my "hack", it had already been thought of by someone else (the
Exodus devs), it in no way introduces incompatibilities since having
stream:error's is a standard part of the protocol AFAIK, so it is not
corrupting anything it is following the protocol and I resent the
implication.

> Example:
> Let's say that jabberd1.4.2 for win32 and linux do not send a
> <stream:error> when shutting down. According to you I'm not allowed to
> reconnect if it sends a stream:error, but it doesn't so I reconnect.
> Now I'm writing a new jabber server SuperExtraXMPPJabberD. When it
> shuts down to restart it's very polite and sends a <stream:error>The
> server is restarting</stream:error> (or if you're still into matching
> CDATA it sends "Disconnected" instead). However users start complaining
> that their clients won't autoreconnect like with jabberd. I "explain"
> to them this lenghty discussion, but some don't care and install a
> different server. Now my marketshare is even smaller :(

Then what you do is use the error codes which are not far off being decided
from what I can gather.

> I have some free time.. and there's a new standard with errorcodes. I
> implement it.. however, the clients don't implement it as fast as they
> could cause they already solved the problem. Well solved.. they used
> some hack you suggested. But hey, it works on all the servers with a
> significant deployment eh?

Well it wont look bad for you since if the clients dont follow the new error
codes and dont try auto-reconnecting when they can do it looks bad for the
client, all you do it recommend a client to them that follows the newer
standard which im sure most (if not all) of the good clients will follow,
thats the great thing about open protocols with plenty of choice of clients.

> I don't think it's the client developers who should be worrying about
> deployed legacy servers. Rather the developers of those servers
> (keeping them updated) and the serveradmins (keeping them upgraded).
> The role of the client developers in this should be keeping the clients
> updated, this will stimulate serveradmins to upgrade, and server
> developers to keep updating since client developers focus their energy
> on implementing the new features they introduce. They do not instead
> use their energy to worry about legacy servers and introducing hacks to
> make it work on those with the largest deployment.

Ok then sure, but if client devs do support the error codes and dont try
auto-reconnecting or stream:errors without codes then IMO that will help
push server admins to update their servers if the users are unhappy about
clients not auto-reconnecting when they could have because the server is out
of date.

> You can disagree with me on this if you want, but I doubt you'll ever
> convince me of something else.

Well fine, but equally I doubt you will convince me, it is others I am more
worried about, you seem to be the only person really voicing much concern.

> When the new stream:error codes are there and enough servers support
> this I would definatly implement this behaviour (no more reconnect on a
> stream:error without code), but not before. This by the way is then no
> longer a hack or corrupting the standard, because servers that don't
> support this are outdated now, and should be updated to the new
> standard. Having my client no longer support it will have the same
> positive effect on server-developers and server-admins who are behind
> on updating and upgrading.

Ah so you agree with what I have just said above.

> But consider your option, if we all drop reconnecting from our clients
> today, the problem of "fighting for resources" will suddenly disappear
> from the "real world". Admins won't be bugged by it anymore since it
> doesn't happen anymore, wich will mean server developers will put
> fixing it a lower spot on their todo lists. Wich means client
> developers and the users are stuck even longer without proper
> reconnecting.

Ah server admins may not have the problem with fighting for resources
anymore, but if they dont keep uptodate then their users will start
complaining to them to update their server because clients arnt
reconnecting. Also because if this if the server has not been updated the
users (server admins) will start to put pressure on the server devs (or
providers) to update or maybe if its one of the opensource servers they
might well do it themselves.

> I think stream:error codes are needed anyway (and I think you agree
> with me on this).

Yup of course

> That doesn't mean it's wrong to give the serveradmin choice. I
> completly agree with Matthew M. on this. We might want to consider an
> approach where there are 3 ways a client can authentice
>
> 1. specifying it doesn't want to hijack the session if it exists (in
> wich case it should always get a 409 if the session exists)

Sure

> 2. not specifying anything (legacy and clients that don't (want to)
> support this. It's up to the admin to decide wether to allow them to
> hijack sessions or not. On a public jabber server I'd allow this,
> unless many what-are-by-then-"old" clients that don't support
> stream:error codes yet cause too many problems)

Sure, thats fine but only once this protocol for electing wether to highjack
a session has been standarised and implemented.

> 3. specifying that it wants to hijack the session if it exists (on
> *any* public jabber server I would allow this, since only the clients
> that properly support stream:error codes should use this option so
> there will be no fighting for resources. In the "paranoia" case of
> Matthew M. or the usefull case of Wes you could still 409 this)

Once this protocol is standardised and implemented I dont see the point in
allowing 409 responses in this case.

> This would also allow a nice extra, a client could first login with
> method 1. If it gets back a 409 it could prompt the user if it wants to
> hijack (we might need a better term here.. I think JDEV has drawn
> enough Echelon attention by now) the session or not and then (if the
> users wants this) try method 3

Yes thats a possibility too.

> Such a proposal would have the best chance of getting accepted if it's
> backed by an implementation though probably (who knows.. I might have
> to write a custom mod_auth in the not too distant future).

Sure quite possibly.

Richard