Simple integration with current technologies is a very real problem standing in the way of widespread Comet adoption. Developers are trained to use a language or framework like PHP, Django, or Rails, where all state information is pushed into the database. There is generally no state beyond what’s needed for the duration of the request. But real-time applications need to keep track of more information and access it more often. Even some very trivial functionality is difficult to integrate with these frameworks.

Consider a Comet application where the application broadcasts a single piece of information every thirty seconds. An administrator can change that piece of information by logging into the application via a web-based GUI. Given a framework like Django, the GUI would be obviously simple to make. But what about the timer? This involves creating a separate thread for the timer itself, and could potentially be complicated depending on kind of server Django happened to be running on top of. This simple app turns out to be very hard to implement in practice due to the nature of synchronous web frameworks.

The timer may seem trivial, but what if your app needs to keep track of connection state? The application could send a PING command out to all of the clients every 30 seconds. If the application doesn’t get a reply (via an XHR requests, let’s say) before the next ping is broadcast, then that browser would be considered disconnected. There is a very real need for this type of feature in many Comet applications, but it is particularly hard to implement with synchronous frameworks.

This could be solved with two steps:

1. 1) Having the Comet server handle connection state, including pings and ping responses.
2. 2) Having the Comet server make HTTP callbacks to the application when timeouts occur.

Now the application need only implement a timeout callback as a particular URL, like any other function of the web application; it’s just an HTTP request with some form parameters. The application can make a note of that disconnect in the database, or inform the other clients as needed. It could even store undelivered messages (from the body of the callback request) in the database for future delivery. The best part is that no timers or any other complicated mechanisms are needed.

In Orbited 0.4 we are including some pre-defined callbacks to make development with synchronous frameworks much easier. These callbacks include message delivery success/failure, signon, and signoff/timeout. We have future plans to include publish/subscribe-specific callbacks so that the web application need only implement a single URL as the publish callback if it needs to react to published information. We also are including callbacks for authentication, which will make it trivial to tie publish/subscribe security to the application’s pre-existing authentication framework.

I believe that the future of widespread Comet adoption is to provide a scalable server that can be easily integrated with existing methods and technologies. No one wants to completely re-learn web development, but they may be willing to learn a couple simple steps towards achieving Comet integration. Providing a simple mechanism to integrate real-time functionality with PHP, Rails, or Django will be a huge win for the Comet community.