Develop a elegant Pub-Sub architecture in web-oriented-apps is a real challenge. Although there are some very interesting solutions using long-polling-connections (e.g. COMET) and repetitive-timeouts (e.g. js setTimeout). IMHO AJAX push still looking like a layer of tweaks and hacks forcing the innocent HTTP protocol.
So what do you think Is AJAX push a HTTP protocol aberration?
Which others alternatives you could consider in a web architecture?
Which others alternatives you could consider in a web architecture?
The HTML 5 Web Sockets API and Server-sent Events look promising for the future. No IE support for Web Sockets yet, and Server-sent Events are still experimental. Douglas Crockford's JSONRequest proposal would also be an interesting alternative to AJAX push, but it is not yet implemented in modern browsers.
For the present, I'll stick with Comet.
Another option I've seen used before is to use a small hidden Java or Flash to connect via plain sockets to the remote server. The server can then push data / events over these sockets at any time, without any polling from the client.
Flash is a little better IMO since it doesn't require a signed applet (which pops up security warnings for the user). It's had Sockets in one form or another for something like 9 years now, though it wasn't until Flash 9 / AS3 that you got 'pure' sockets that you could use to connect to any type of service (previously it required that messages be terminated with a 'null' packet, meaning you had to design your protocol specifically for flash, instead of being able to use XMPP or SMTP or any existing protocol)
Polling is the web-architecture way of doing pub-sub. It works well when clients poll infrequently and the responses can be cached and shared (for example, the rss feed of a blog). Keeping a tcp socket open per client, like with comet, is not the ideal way of using http. However, if your app runs in a web browser, and needs frequent, unique, per-client updates, that's not a bad way of doing it.
Comet and polling for per-client resources are not completely abusive to http or the web -- it's just that http and the web were designed particularly to share the same resources (ie web pages) among many clients, so that's the way it works best.
Just think about the most common Comet implementations, just the fact that you have to fool the browser into thinking that it's receiving a multipart response or an infinitely long html inside an iframe is enough to raise a flag on whether this is the appropriate technology or not for the job.