On Mon Jun 13 10:08:58 2011, Glenn Maynard wrote:
On Mon, Jun 13, 2011 at 4:04 AM, Dave Cridland <[email protected]>
wrote:
> On Fri Jun 10 18:48:01 2011, Glenn Maynard wrote:
>
>> This won't work properly if the existing client is a paused BOSH
session,
>> which may not unpause the session to reply for arbitrary lengths
of time.
>>
> So it times out. No problem. Still works properly, everything's
happy and
> jolly.
>
BOSH sessions may have pause sessions hours long. Taking an hour
to time
out isn't jolly, it's broken.
No, we don't wait for a response to time out. That's why it's called
"timing out". :-)
Even the more common case of pauses on the order of minutes would
be a
clearly unacceptable delay. I don't think designing around expected
timeouts is a good approach.
No, it's a fixed timeout in the order of ten seconds. There is
nothing a client can do (including explicitly pausing the session) to
avoid this.
It's not one client involved, but two, and any time the right
behaviour is
> dependent on more than one entity doing things right, disaster
lurks in the
> wings.
>
> If one client does it right, and another does it wrong, there's
some nasty
> failure cases.
How is a buggy client ever going to accidentally conflict with a
SHA-1 based
resourcepart? (Or even something much shorter--you don't need 160
bits to
prevent that.) The point is using resourceparts designed to
prevent these
accidental conflicts.
Turn it around - how is your problem not solved by the solution
already in existence?
Dave.
--
Dave Cridland - mailto:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
