The AJAX Push session was interesting, although right now I can’t see too many situations where Shine would need this kind of technology. Let’s put this in perspective with the decision tree for even thinking about it:
- your application is a web application
- your application uses AJAX
- your application has events that can happen on the server
- events on the server need to be communicated to the user in near real time
- the user has a browser open all the time simple polling from the client to the server is either too slow (you can’t poll fast enough to meet the latency requirement)
- simple polling places too much load on your server and you can’t just scale via hardware
So, as you can see there aren’t too many situations left! In reality only sites like Google Mail, GTalk and Meebo definitely need it due to their massive number of users and equally massive budgets.
Still, the key point is that there are two main approaches, the ‘long poll’ or ‘streaming’. Since a server cannot arbitrarily call a particular browser, the term ‘push’ is a little misleading. The ‘long poll’ implements an approach where the browser puts in a call to the server when it loads, then the server responds whenever it likes. After the response the client starts a new call back and again waits until the server has something to send. This is a simple request – wait – response cycle. In ‘streaming’ the client again opens a request, but the server just responds with chunks of data down the stream and only closes when the session ends.
Long story, but really only the ‘long poll’ is practical. There are enough technical difficulties with streaming that I can’t see how it will practically work (small example: IE doesn’t stream, so it won’t work).
Overall, interesting to see how it is done but as I mentioned at the start I am not holding my breath for a commercial opportunity where Shine would need to use it.