>>the "flooding the server with calls" is a non argument. If you don't >>want to do that, then you need to redesign your server side code to >>accept a single request to give you all the data you need
Not true .. well at least I don't see it as that. I have no probs with multiple calls hitting the server at once. If you can't write scalable code, then that's your bad luck and out of scope of this discussion. This leads to this quote: >>As for "queueing up ajax requests", doesn't that defeat the purpose of >>an asynchronous environment? Afterall, the end result of queuing up >>requests is a synchronous routine. Why not just load another page that >>does everything you need? and >>But, >>if we cannot clearly define what you are trying to do, then we cannot >>clearly tell you if it's in core jQuery, or in a plugin.. :) Also not true .. actually far from it .. and i'll use the example i want to do, to illustrate this. I'm doing some Ajax calls with my google maps, so when the map is panned, an ajax call hits our server to retrieve some data to show ON the map. Easy. Now, the problem lies when users pan-pan-pan-pan-pan .. ie. do lots of pans in quick succession. Now having 5, 6 or even 10 hits to our server is not a problem. It gets messy when the browser is trying to download lots of google map tiles AND then render hundreds of pins (our results from the ajax) .. especially if all the results are coming back async. So to help relieve the pressure on the client side, by having an ajax QUEUE client side, the results will only be rendered one at a time. By default, the browser will try to hit the server the with the max number of connections to the same domain (eg. Internet Explorer is defaulted to 2 connection, prior to IE8 i think). that's what i'm trying to do and why i believe it's important. It's also for scenario's with latency issues ... check this vid out (and ignore the fact that it's about script.aculo.us): http://www.phppatterns.com/stuff/latency.html does that make more sence? -me-
