Just ran across a few great ideas on the tubes last night whilst reading about REST philosophy (one of my casual interests).
Anybody hear of ETags? A HTTP1.1 standard header that I'd never heard of. Idea is this:
An ETag is a hash of a previous data response. Each time you sent a specific data request, you send along an ETag that represents a hash of the previous data. It's like a cached copy, but without all the wasted space. When you send along your ETag in the HTTP headers, the server receives it. It compares the ETag with the hash result of the data you requested. If it's the same, it returns a 304 Not Modified instead of a 200 Success, which you can handle in the ajax callback as you see fit. In any case, it will be much faster to receive and handle with no data! Now, typically this is done by attaching an ETag to a specific URI, i.e. GET request, where the parameters specify the exact request you are making. This would mean, however, that POST requests would not cache an ETag properly, with details in the message body. No matter, however, as you can store your own ETag in your js objects that you pass around with your requests if you like, which is what I plan to do.
The advantage of using this instead of something like open sockets or long polling is that you don't need a handler running on the server side to determine when updates have been made and then send them back to the client. Not to say that there is anything wrong with long polling or things like sockets, but I'm lazy and don't want to write server-side code to handle every case of "data has changed, notify client!". The general Not Modified possibility will save overhead on everything with very little work.