Here’s a podcast about Comet – exploring the two-way web with Ajax. From my Ajaxian post earlier today:
Alex Russell has coined a term for a flavour of Ajax that’s been getting more attention of late. Comet describes applications where the server keeps pushing – or streaming – data to the client, instead of having the browser keep polling the server for fresh content. Alex identifies several buzzworthy examples:
This is an important article because it captures a growing trend in Ajax, a trend I had in mind when I said we expect to hear more about “Push and the Two-Way Web” in the next twelve months, on the occasion of Ajax’s birthday. There will, of course, be people saying “there’s nothing new here”, and that’s presumably all too obvious to Alex himself, who has worked with these ideas for a long time. But as with Ajax, it’s the power of a name. I don’t think these ideas can adequately be described as Ajax, because Ajax changes a lot about the browser whereas Comet fundamentally changes the nature of browser-server communication. I see Comet as part of the overall Ajax trend, complementary to the UI aspects of Ajax.
People may also say there are existing names like “Push”. True, but they have baggage – I think it’s useful to have a name for this architectural pattern in light of the relationship to Ajax.
Anyways, I wanted to expand on some of the thoughts in the article and after the recent Basics of Ajax Podcast, I’m in the mood for more audio rambling. So here’s a 56-minute discussion about Comet and the general trend of push and streaming within Ajax.
It's the Duplex, Stupid! Push or Pull - it doesn't matter so much. What's critical here is the focus on the two-way web.
Applications - Chat - Wiki - News - Current events, sport, financials, etc - Trading and Auctions - Real-time control and logistics - File transfer (combine with local storage) - Any other genre you'd care to name
Vanilla Ajax: Await the User
Comet Ajax: Keep Pushing
Polling Ajax: Keep Pulling
Benefits of Comet - Responsive: data pumped out immediately - More stable profile - Less overhead of establishing connections
Benefits of Polling - Browser memory - Can run on any standard server; Comet requires suitable server - Can upload at the same time - Can run on - with Comet, XHR and IFrame won't always reflect changes while the connection's open - Being more standard, works with existing infrastructure. Comet is vulnerable to middle-men dropping the connection. - Simpler architecture - only the browser's in control - Easier to test - More familiar architecture - Less programming effort - with Comet, must watch for changes on the stream - More efficient for infrequently accessed data - Leverages caching
Maybe Comet causes more pain, but if it keeps the user happy ...
Questions and Trends - Which to use. Variables include: frequency of updates, importance of updates, server capabilities, target browsers - Dealing with incoming messages, e.g. Distributed Events pattern, Event bus (browser or server?), etc - Workarounds for throbber, status bar, clicking sound, etc. - How often to drop connections - How browsers can accommodate it
Proof-Of-Concept Demos - Wiki using Periodic Refresh/Polling - Wiki using HTTP Streauh, Comet (Actually, this is only a very basi implementation - there's no use of events, just custom handling of HTTP.
As always, feedback is welcome – [email protected]