HTTP is unidirectional by design. It is always the client (web browser) that submits or requests information. The web server just waits at the other end and processes whatever requests it receives. For many applications it would be beneficial if the server could propagate events to the clients as they happen. For example a chat application would like to push new messages to all connected users, or our todo application would like to push updates of the model to other people working on the same list.
Even today, the most common solution to this problem is to use polling. That is, the client regularly queries the server for new information. The only way to decrease the latency is to increase the polling frequency, which causes a significant load on the server. In practice one would like to avoid both a high server load and high latency.
In March 2006 Alex Russell coined the term Comet in a blog post to describe an alternative approach: one where the server keeps its connection to the client open, and continues to send updates to the client through that connection. The idea that Alex describes in Comet was previously known by a variety of terms like ‘reverse AJAX’, ‘HTTP push’, ‘server streaming’, etc, but Alex’ post popularised the concept.
Comet was incorporated into Seaside only a few months after it was introduced.