Comet: It’s Ajax for “Push” (Podcast)

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.

Click to download the Podcast. You can also subscribe to the
feed if you want future podcasts automatically downloaded - check out the
podcast FAQ at http://podca.st.

Shownotes…

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.

Related Patterns - HTTP Streaming - Periodic Refresh (aka Polling) - Distributed Events

As always, feedback is welcome – [email protected]

9 thoughts on Comet: It’s Ajax for “Push” (Podcast)

  1. Long time listener first time commenter :) Love the podcast and I’m happy to hear you’ve started recording new shows :)

    Anyways, I have a slight beef with your description of adding onclick handlers to objects.

    Say we have some html: click me!

    and some javascript: (using your method of adding click handlers) window.onload = function() { clickme.onclick = function() { alert(“I was clicked!”); } }

    now, this works in most browsers, but it’s not W3C compliant. Firefox will yell at you if you do this. The ‘proper’ way to do this is to add your event handler like this:

    document.getElementById(‘clickme’).onclick = function() { alert(“I was clicked”); }

    now, typing document.getElementById() every time is a big pain :) Which is why I choose to use prototype.js (http://prototype.conio.net) to abstract a lot of the browser differences. prototype.js includes an alias to document.getElementById (with a couple of extra features) you can call via $()

    so …. the above code would now look like: $(‘clickme’).onclick = function() { alert(“I was clicked!”); }

    but then… I would also take this a little farther, and use behaviour.js (http://bennolan.com/behaviour) .. but that’s of course, a personal preference :)

    Thanks and keep up the great work with the podcast!

  2. apparently it’s stripping out the < > I had in the previous comment. Where it says “click me!” there should be:

    <button id=”clickme”>Click me!</button>

  3. Hi Jeremy,

    I’m guessing this relates to the recent Basics 3 of 3 podcast (I did two this week, bit confusing after 100+ days off ne).

    I think I agree with you. In all the code examples, I use $() myself, convention yanked straight from prototype.js. I’d only use clickme.onclick if clickme was a JS variable, that’s probably what I meant on the podcast, which just goes to show why code snippets don’t make for very good podcast content :-).

  4. Pingback: Ajaxian » Comet ETech Slides Available

  5. Pingback: » Like, Comet is the new Ajax, duh! :: Nate Ritter ::

Leave a Reply