@Peter I think XEP-0124 is quite explanatory. Just that the developers who try to find 2 simultaneous pending requests in their firebug will get foxed.
@Matt Yeah it doesn't make a difference (xmpp or event based approach). In any case server always have a request from client to which it can reply to. However in case of xmpp it's another extra request which serves this purpose and in event based servers this extra request can be saved. Abhinav Singh, Bangalore, India http://abhinavsingh.com/blog ________________________________ From: Peter Saint-Andre <[email protected]> To: Bidirectional Streams Over Synchronous HTTP <[email protected]> Sent: Mon, January 11, 2010 8:44:08 AM Subject: Re: [BOSH] Pipelining / avoiding use of 2x HTTP-sockets 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
