cometd-perl

cometd-perl

cometd-twisted

twisted python

sandbox

☄ cometd-js

A Bayeux implementation server will be released at some point that is written in pure JavaScript on top of Rhino. This is an effort to provide users with an all JavaScript stack that can be easily customized by anybody that understands JavaScript.

If you are interested in the effort (currently closed source) or are interested in obtaining a copy of the code, please send an email to bob.remeika@gmail.com

2.0.beta Release Notes

Cometd 2.0 is in Beta release and represents a significant refinement of the cometd codebase. As such many of the APIs have changed and much of the documentation on this site needs to be updated. This page provides notes to assist users of the CometD-2.0.beta releases until such time as the documentation has been updated.

Cometd 2.0 What's Changed

Javascript Client

• Abstracted Transports to new transports to be developed and plugged in
• Websocket Transport that uses the HTML websocket API from HTML5.

Java Server

• Major rewrite of the entire code base, with many rationalizations and simplifications.
• New API in org.cometd.bayeux and org.cometd.bayeux.server packages.
• Websocket Transport that uses the HTML websocket API from HTML5.
• New hierarchical and extensible configuration parameters

Java Client

• Major rewrite of the entire code base, with many rationalizations and simplifications.
• New API in org.cometd.bayeux and org.cometd.bayeux.client packages.
• Distinct Client APIs for a remote client and a server-side client (now called session).

Cometd 2.0 Java API

The 2.0 java API has been decomposed into common, client and server parts, with the following new concepts:

Message

The Message class has been split between an immutable Message API and the Message.Mutable API. The API has been carefully designed to only pass a Mutable message when it is OK for the application code to modify the method (there is no longer a need to know when to clone the message).

On the server, the ServerMessage sub-interface provides extra methods for associating messages, lazy messages and reference counting. Also the server enforced immutability deeply into the message map of maps.

Session

The Client API has been renamed Session, to avoid confusion between server side client and client side clients. A Session has an Id (still called clientId in the protocol); a connected state and associated attributes.

All Sessions (local or remote) have a user facing API (ClientSession) and a server facing API (ServerSession) that represent both ends of a cometd connection. The server can have local connections, which use the LocalSession sub-interface of ClientSession.

The ClientSession sub-interface provides methods to subscribe and publish to channels via a SessionChannel interface.

The ServerSession sub-interface provides methods to listen to incoming messages from the session, deliver messages to the session and to look at the queue of messages waiting to be delivered.

Channel

The common Channel interface just provides the channel ID and related methods.

The SessionChannel interface is a Channel scoped to a particular ClientSession and provides methods to publish and subscribe the session to the channel. There is also a MessageListener mechanism, which differs from subscribe as it listens only to messages that happen to arrive and does not send a subscribe message to the server requesting subscription.

The ServerChannel interface provides the servers view of the channel and has methods to access all subscribers.