Friday, March 28th, 2008
There has beern a lot of great Comet content recently, especially from Comet Daily of course :)
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:
- Part 1: Greg Wilkins explains the need for Bayeux
- Part 2: Michael Carter criticizes the current state of Bayeux
- Part 3: Greg Wilkins responds to Michael Carter
- Andrew Bettsâ€™ thoughts (from a related article)
- Part 4: Michael Carter responds to Greg Wilkins
- Part 5: Kris Zypâ€™s thoughts
- Part 6: Alex Russell responds to Michael Carter
- Part 7: Michael Carter responds to Alex Russell
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