Friday, December 7th, 2007

Comet. Not as painful as you think!

Category: Comet

<>p>Simon Willison was worried that the amount of complexity involved with Comet meant it was out of bounds to all but the most dedicated JavaScript hackers but after playing with it, concluded:

I’m pleased to admit that I was wrong: Comet is probably about 90% of the way to being usable for mainstream projects, and the few remaining barriers (Bayeux authentication chief amongst them) are likely to be solved before too long. I expect to see many more sites start deploying Comet powered features over the next twelve months.

For Simon’s presentation he built the slideshow itself as a Comet app. He could move the slideshow forwards and backwards, and anyone connected would also see the slides move. A nice touch. He used Jetty as the web server, and Dojo as the client:

javascript
< view plain text >
  1. dojo.require("dojox.cometd");
  2. jQuery(function($) {
  3.     dojox.cometd.init("http://example.com/cometd");
  4.     dojox.cometd.subscribe("/slideshow/change", function(comet) {
  5.         $('#currentSlide').attr('src', comet.data.src);
  6.     });
  7. });
  8.  
  9. function publishSlide(src) {
  10.     dojox.cometd.publish("/slideshow/change", {
  11.         'src': src
  12.     });
  13. }

Related Content:

Posted by Dion Almaer at 6:49 am
6 Comments

++---
2.8 rating from 70 votes

6 Comments »

Comments feed TrackBack URI

The example he uses in Jetty is rather difficult to understand due to the lack of proper documentation for cometd and dojox.cometd. I would have to disagree with Simon :-(

Comment by getter — December 7, 2007

Me too, code is not readable for me since I am unfamiliar with those functions, but I will agree that it is short and concise :) But hey, I’ll bet all of the documentation is at the actual blog that is linked to, so my laziness is the culprit!

Comment by Chad Wagner — December 7, 2007

The dojox.cometd APIs used hare are *all* of the APIs you’ll see as a developer. They (in order of appearance):

* open up a bi-directional tunnel with a Bayeux server. Once a connection is opened you can publish JSON messages to a named topic and subscribe to hear about messages that you (or other senders) publish to those topics you’re subscribed to
* subscribe a handler to a particular topic
* publish a JSON message to the topic. The serialization of the message into JSON and the wire-level details are all handled for you by the client library.

You send and receive pure JS objects, and it’s all JSON on the wire.

Comment by Alex Russell — December 7, 2007

The problem of Bayeux protocol is it requires a Bayeux server, the spirit of COMET is server push, the client receives asynchronously some data (or JavaScript) from server. A “simple” approach is using AJAX under the hood to transport XML or JavaScript when the server generates this data, the server can generate the JavaScript code to generate a new AJAX request to continue listening too.

In ItsNat the COMET approach is amazingly simple, only a special Java method is called in the server, CometNotifier.notifiyClient(), and the server will send to the client any pending user defined JavaScript code to the client. This JavaScript code is executed “as is” in the client.

Comment by jmarranz — December 8, 2007

jmarranz:

perhaps i can frame your objection to Bayeux as a protocol a bit differently: by needing a compliant protocol server, Bayeux encourages interop, a proliferation of clients and servers, and allows anyone to layer behaviors like what you’re talking about (sending code to be executed) on top of an orthogonal protocol stack. Joe Walker and Greg Wilkins have alpha-level Bayeux support in DWR to achieve exactly this: let each level of the stack do what it’s best at and plug them together.

Instead of being one-off, tied to a particular implementation, and requiring you to build the app from the bottom up w/ Comet features in mind, Bayeux lets you put your Comet server in your infrastructure *after* the app it built/deployed….which basically means that railing against lower-level protocols like Bayeux just doesn’t even make sense. ItsNat does something one level up the stack…great! That doesn’t make Bayeux less valuable nor does it imply that they’re mutually exclusive (except for implementation decisions by the ItsNat team).

Regards

Comment by Alex Russell — December 8, 2007

Ok, Ok Alex don’t bother, Bayeux standardization is fine if you follow the client route and you don’t want to bind your client centric COMET technology to any specific server technology (not a Bayeux based). I’m on the server side and see the world “server centric” :)
Regards

Comment by jmarranz — December 9, 2007

Leave a comment

You must be logged in to post a comment.