On Oct 7, 2008, at 12:20 PM, Pavel Simerda wrote:
On Mon, 6 Oct 2008 11:39:11 +0100
Pedro Melo <[EMAIL PROTECTED]> wrote:
On Oct 5, 2008, at 1:48 AM, Jonathan Schleifer wrote:
"Matthew Wild" <[EMAIL PROTECTED]> wrote:
If they type it manually then they know what they are doing, and
when they come to type the stanza for resource binding, they will
read the RFC and see that it recommends not specifying a
resource :)
Which is IMO a painfully bad idea for users with instable
connections. They will have thousands of resources online after a
short while and you don't know which to msg. Very, very bad idea,
IMO. Makes it totally
unusable with an unstable conenction. You *WANT* a static resource
then, so you can replace the old, dead connection.
I would recommend those clients to use BOSH and its native session
resume capabilities.
I would recommend not to break the TCP way only to use a bunch of
layers. Too many layers (in protocol, session layers, etc) add
(usually
unnecessary) complexity.
Sure, but the scenario was unstable networks. On those networks, you
need a strong session-level reconnect protocol, and right now, XMPP
over http BOSH has that, and XMPP over TCP doesn't.
The users will be a lot happier.
On a perfect world you would be able to use the same session-resume
capabilities on TCP. Maybe someday you will.
That would be much better. But still it doesn't solve the "disconnect
without reconnect" case (xep-198 mostly does).
"disconnect without reconnect"? you mean when a client looses the
connection and doesn't reconnect in the allowed time?
It would trigger the longest allowable time period for session
resumption timeout.
In XEP-0198 (see example-2, http://xmpp.org/extensions/xep-0198.html#example-2)
, the servers sends you back a max attribute with the longest
allowable time to reconnect. If that expires, the server assumes the
connection is dead, and cleans up.
Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: [EMAIL PROTECTED]
Use XMPP!
