Matt's summary is correct. Perhaps we need to more clearly explain this in XEP-0124.
On 1/10/10 7:58 PM, Matthew Wild wrote: > 2010/1/10 Abhinav Singh <[email protected]>: >> Yup thats what i have observed with xmpp and wrote in my last mail. Thanks >> for digging another level to explain the same. >> But my question was, why is a previous request replied back in case another >> request comes from the client. >> >> When i work with event based push server, i can actually avoid empty >> response to client request which was on hold before. >> By doing so, I save unnecessary another request going from browser to the >> server. >> >> == xmpp case == >> a client request is on hold looking for new data from server > > Yes. > >> a new client request goes for publishing a message > > Yes. > >> server respond to previous holded request, and then process next incoming >> request > > Yes. > >> finally client fires another request to maintain that 1 necessary connection >> with CM. >> > > No, the client already just fired a request, remember? The server > never replied to this one, and it becomes the new "held" request. > > Whether the server replies to the newest request or oldest request > doesn't make that much difference, but the latter seems cleaner and > technically better (and this is what happens). > >> == event based push case == >> a client request is on hold looking for new data >> Another request comes from client for publishing a message. >> Server respond to client's new request while still able to hold previous >> request by the client. >> > > Same as BOSH, except in BOSH the oldest request is replied to (and the > newest is put "on hold" to replace it). As I said above, it doesn't > make much difference, implementation just makes more sense this way. > > Matthew
smime.p7s
Description: S/MIME Cryptographic Signature
