> You'll have to deal with this anyway, or you'd process responses in > the wrong order. It shouldn't be difficult to deal with this with > XHR. In rough pseudocode, it'd look something like this:
So, just to give a further example as to why I would prefer decoupling the request & response IDs, assume that you are on a flaky network (most mobile clients are). Many connections get broken when the server tries to send a response on them. So, you got say 2 requests with: rid=10 and rid=11 after a few second, the xmpp server sent a response which should have gone out on rid=10. However, while writing to the socket, the connection broke. According to the spec. there are 2 possible ways of handling this (assuming ACKs are enabled): 1. Wait for the client to re-request rid=10 (possibly wait timeout period which is quite a while). 2. Send the response on rid=11 and mark rid=10 as an empty response so that when the client re-requests it, it gets an empty body. In either case, the client can't process the response on rid=11 till it knows the contents of the response on rid=10 since it would result in an inconsistent stream. Instead, however, consider that response IDs were unrelated to request IDs. In such a case (for the scenario above), the BOSH server would send the next valid response ID on rid=11 and the client would readily gobble it up and not bother waiting for the response on rid=10 (it would need to re-send it though). When it does re-send it, the server will simply ignore it since it already processed rid=10. I feel this would cut down on a lot of wait time on the network and would result in a generally better user experience. Is there anything that I seemed to have overlooked? Regards, -Dhruv. -- -Dhruv Matani. http://dhruvbird.com/ "What's the simplest thing that could possibly work?" -- Ward Cunningham
