Friday, March 28th, 2008

Comet Roundup: Gazing, Battles, and Protocols

Category: Comet

There has beern a lot of great Comet content recently, especially from Comet Daily of course :)

First, they gazed at their own Comets talking about maturity, together with a maturity grid. Since the project leads and vendors are grading themselves, you have to do due diligence :)

Joe Walker has written up 3 styles of API that are relevant when considering Comet services, which are:

  • Traditional API Style. This API is the most obvious. If you want to set the text of a button, you call
    field.setValue(43.5) or something similar. It’s possible to imagine complex APIs like the SWT library made available remotely. This type of API does not need Comet, unless the trigger for wanting to alter the UI is asynchronous.
  • Message Passing Style. This API style is very simple—typically just a subscribe() method to declare an interest in some topic, and a publish() method to declare some information to a topic. Some messaging APIs (notably JMS) add a large number of classes around this simple concept, however at its core, it’s as easy as those 2 methods.
  • Synchronized Data Style. This style involves some data cache on the server that is synchronized with a similar data cache on the client (or clients).

Joe then walks through the pros and cons, and includes information on how DWR does its thing.

Colliding Comets: Battle of the Bayeux

The entire crew has a series of back and forth opinion pieces on the Bayeux protocol:

Martin Tyler of Liberator has a nice piece talking about benchmarking Comet servers which concludes:

Benchmarking Comet servers is not easy. There are lots of variables which impact the results, often in an unexpected way, so the only way to be sure is devise and run the appropriate tests. Making assumptions while testing is not good; if you need to know something it should be measured and recorded.

It is possible to achieve high numbers of users with high update rates and relatively low latency. However, a project needs to understand the implications, such as bandwidth, which are inherent in the requirements rather than the technology. A serious project should also perform benchmark tests themselves, with test scenarios similar to expected usage, rather than just looking at some headline figures from the Comet server vendor.

Finally, Zaid Al-Timimi has released XML Studio 7.3 which has Comet developer support.

Developers can now build and test real-time streaming mash-up applications. Version 7.3 embeds a copy of the upcoming <alt> Dynamic Mashup Server which uses a custom version of Grizzly, the Comet technology from Sun.

Posted by Dion Almaer at 5:56 am
Comment here

2.9 rating from 14 votes

Comments Here »

Comments feed TrackBack URI

Leave a comment

You must be logged in to post a comment.