I\'m needing to build in some pretty agressive \"auto refresh\" capabilities into a web application. It\'s kind of a photo gallery and the images are stored on AmazonS3 but the
WebSockets seems like a fairly good choice. The disabling of WebSockets in Firefox 4 and Opera 11 is likely temporary as the working group has begun releasing drafts that address the issues. In addition, the web-socket-js Flash fallback will still work even on browsers where native WebSockets has been disabled. Also worth noting is that iOS 4.2 has native WebSockets. So with native WebSockets + fallback, WebSockets is supported just about everywhere.
If you use WebSockets you also might want to consider pushing updates rather than having the clients poll. This will help keep the clients from accidentally DDOSing the server. Latency will just go up for the clients and at that point you can start adding more resources on the server side.
If server-side Javascript is not out of the question, then you might check out Socket.IO which is a Nodejs WebSockets framework that picks the best transport that both the client and server support automatically (preferring native WebSockets, then WebSockets fallback, then various long-polling options). It also enables the server and client code to look very similar because it includes a client side library. Socket.IO seems to have a fair bit of mindshare at the moment.
If you are Ruby centric you probably want to check out em-websockets. Both Socket.IO and em-websockets are event'd based server which allows very high client counts especially where latency rather than bandwidth is paramount.