A Taxonomy of Event- and REST-based Comet

by Kris ZypNovember 21st, 2007

Applications of Comet can be roughly categorized into event- and REST-based messaging. The characteristics of a Comet application define which Comet model is used, and different technological approaches can be used to maximize performance and scalability based upon the form of Comet.

Event-based Comet

In event-based Comet, messages are sent between agents with no assumptions about the meaning of the messages. One of the most common forms of event messaging is the publish/subscribe mechanism based on channels, in which agents can subscribe to channels and publish events to channels. In this form of Comet, messages are explicitly formed by agents, and the only commonly understood meaning attached to the message is the name of the channel. Beyond that, agents must understand what the messages mean and the impact of the messages. The underlying mechanism can not make assumptions about the requirements of the delivery of the messages or about acceptable message reordering. The Bayeux protocol is well designed for this form of Comet.

User-centric Event Messaging

User-centric event messaging is a particular form of event messaging that is used for chatting. While the publish/subscribe mechanism usually uses string-keyed channels, in user-centric messaging channels equate to users. Each user represents a channel, and the user is implicitly subscribed to their own channel. In terms of pub/sub channels, when other users wish to send a message to a user, they essentially publish an event to the other user’s channel.

Data-centric Comet

Comet can also be used as a data synchronization technique. In these types of Comet usages, applications present users with information that is volatile and subject to frequent and meaningful change, and Comet is used to keep the information up to date. In Joe Walker’s case for Comet, he argued that the reason for the growing importance of Comet is that we spend more time on a page, while the information behind it is changing faster. This type of scenario that he described is data-centric Comet. In this form of Comet, messages are pushed to clients to alert them to changes in the data, so that clients can have the latest available data.

Comet used in this manner can take advantage of meaningful semantics that provide information about the purpose of messages and how that purpose impacts delivery constraints. Comet can actually be advised by the concepts of Representational State Transfer (REST) that have provided the scalable architecture for pull-based HTTP. The concepts of REST and perhaps even the semantics of HTTP can be applied to push-based communication. There are several properties of this form of messaging that can be used advantageously for architecture and abstraction of data/messaging interoperability.

REST Comet

Borrowing from REST, we can define messages in terms of what resource they operate on. Each resource has a unique identifier (URI for example) that identifies the resource. Messages are then composed of updates representing the data resource they reference. Semantics can indicate whether the message contains the entirety of the resource (as GET and PUT do in HTTP). An important consequence of this form of messaging is that architectures can understand when messages supersede previous messages. It can also understand the idempotence of messages. Frameworks can also utilize the REST semantics to understand how synchronized data needs to be updated.

For example, a stock ticker is a type of data-centric Comet application. How can we apply REST to a stock ticker? Let’s assign a URI/id to one of our stocks, which we will call: http://mystocks.com/ACME . Now let us assume we can get the value of the stock by simply doing a GET request at that address and getting the value:


Now suppose that we have a Comet connection and that we receive a message:

URI: http://mystocks.com/ACME
method: PUT

If a client understands HTTP semantics here, it can evaluate this message as an update to the data resource provided by http://mystocks.com/ACME .

Another message could be sent to the client with a body of 13.01 to provide an even newer value for the resource. Some significant advantages can be derived from a convention with commonly understood REST semantics:

  1. Generic code can be written to handle messages as data modification requests and properly update data corresponding to the identified resource. This can be handled without specific code for each message.
  2. Architecture can make optimizations based on messages. When a PUT method is pushed to a client, the idempotent nature of the message can inform optimization. The message can be sent multiple times instead of once without harm.

Also, if another message referencing the same resource is queued to be sent to a client, the previous message can be safely discarded, as it is not necessary for the client to be made aware of the in-between state. For example, when a third update to the ACME stock is available to send to the client, it is no longer necessary to send the second one. If it is still in the queue it does not need to be sent, or if it failed to be sent, it does not need to be retried. This allows architectures to realize flexibility in distributing messages at a different rate than receiving them. For example, a stock server may be receiving updates on the ACME stock every second, but if resources such as bandwidth are slim, it can safely adjust and scale back the number of updates it sends to client (perhaps one every three seconds).

In Between

Some applications of Comet blur the line between event and data centric usage. For example, a progress bar may receive messages pushed from a server about the update of an operation. The messages may indicate the percentage of completion. Such messages can utilize the idempotent characteristics of REST Comet, with the latest percentage update superseding all previous messages. However, at the same time progress bars do not usually reference persistent resources, but rather transient actions.


By understanding the application of Comet, architecture and messaging semantics can be adjusted to facilitate optimum scalability and meaningful communication. In data-centric applications, the concepts of REST and the HTTP definitions can be utilized for broadly understood semantics for resource update based messaging. The format of how to communicate these meanings is open question to explore.

4 Responses to “A Taxonomy of Event- and REST-based Comet”

  1. Rick Dunlap Says:

    Wouldn’t it be more natural for a resource change notification be limited to only the new resource’s representation and not the method? The method is confusing and unnecessary. It seems to imply that the server is doing a ‘PUT’ to a resource belonging to the client when in fact it is notifying the client of a change of state of the server resource.

    Also, it seems that HTTP headers for the resource would be problematic. A simpler approach would be for the client to be notified of a change in a resource simply through it’s URI. The client could then do a ‘GET’ on that URI exactly as if it were polling the resource.

  2. Kris Zyp Says:

    Rick, I think there is value in being able to communicate what type of resource change is taking place; a replacement representation for the resource (PUT), an addition to the resource (POST), or the removal of the resource (DELETE). Simply sending the representation is not adequate to communicate that these messages efficiently. In particular, messages that represent additions are very useful. Consider a Comet stream that is notifying on changes to a RSS resource. It is much more useful to simply receive each addition/new entry than receiving the entire feed each time. This also equates nicely to event based messaging.
    However, while I believe these methods have very valid analogies in notification, they may be confusing because normally the methods are instructing what should take in place, whereas with a notification they are informing about what already took place. I don’t believe it is illogical to send PUT request for a resource that does not belong to the recipient machine, I believe this is how HTTP messages (PUT included) are routed through proxies. I think the main difference and point of confusion is traditional HTTP messages are before the operation, notification HTTP messages are afterwards. For the sake of clarity, this may very well be grounds to use different more clear methods (maybe PUT -> UPDATED, POST -> ADDED, DELETE -> DELETED?).
    I think your other suggestion was to do GET requests that simply does not return until the resource changes. If that is correct, I think it is an excellent approach, and I have definitely been wanting to explore that more, especially as possible technique for RSS/Atom feeds. You are right that it is simple, and that is very attractive.
    Thanks for the comments, I am working on another article to explore these ideas deeper.

  3. Comet Daily » Blog Archive » Symmetric vs. Asymmetric Comet Says:

    [...] Zyp recently categorized Comet applications into event-based and data-centric Comet. I will try to expand on this by mapping such definitions to two general types of publish/subscribe [...]

  4. Comet Daily » Blog Archive » Pub/Sub’s relationship with REST and RPC Says:

    [...] message. A message to subscribers may also be the result of another action with side effects like a REST command, or caused by another assymetrical [...]

Copyright 2015 Comet Daily, LLC. All Rights Reserved