Colliding Comets: Battle of the Bayeux Part 3

by Greg WilkinsFebruary 11th, 2008

In part 3 of this series, Greg responds to Michael’s criticisms of Bayeux from part 2.

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

Welcome to Comet Celebrity knock down!

I see the criticism contained in Michael’s article as mostly indicating that the Cometd project has failed to communicate the features and intention of Bayeux. This is mostly due to our poor project documentation (insert pathetic excuse about project infrastructure, time etc.)

So I think the best rebuttal I can give is to correct a few misconceptions that Michael has.

Broadcast - Michael suggests that broadcast use-cases do not need the “cost” of Bayeux and that “The URL itself is enough of a subscription request for this information”. But broadcast does need a very important feature of Bayeux: transport negotiation! Without a standard for that, your broadcast application will be tied to a single transport.

A single request is needed to handshake most transports, and then another request will subscribe to whatever broadcast channels you are interested in (e.g. earthquakes and storms, but not floods and fires). If you want to specify that in a URL, then use a transport that allows URL encoding of subscribe messages.

Peer to Peer - Michael correctly identifies that there is unacceptable cost in having user specific channels for user specific messages. That is why Bayeux includes /meta/* and /service/* channels. These channels are not broadcast channels, and when a client publishes a message on /service/takeItem, it is only delivered to the server and not to other clients subscribed to /service/takeItem. The server that handles the /service/takeItem channel can deliver message(s) back to a single client via the same channel so that the client can be informed of the success or failure of their take item (and what the item is etc.) in Michael’s example.

The use of /service/* channels greatly removes the need for most per client channels and dramatically reduces server resource requirements. It is a failing of the Cometd project that we have not well documented this feature.

I also disagree with Michael’s premise that the “cost” of any unused features in Bayeux will stop developers from implementing it. We don’t expect that many developers will implement Bayeux, unless they have some new idea, language, transport etc. The vast majority of developers will simply use one of the growing number of existing implementations. And how many of us really use all the features of the frameworks that we have at hand? The important question here is what the cost of unused features is. For Bayeux, the cost is a single request to negotiate the transport before the business of subscription commences. Even a subscribe request can return valuable payload. The cost of Bayeux is small.

I’m not going to comment much on Michael’s proposed layered solution other than to say that I’m not opposed to layering. The Jabber/BOSH protocol appears to have done a very good job of specifying the use of 2 HTTP connections to provide full duplex communications. I’d love to see BOSH as a transport option for Bayeux. Even though there is some overlap, BOSH is definitely pitched more at a specific transport while Bayeux is pitched more at a specific semantic.

Finally, take Michael’s prediction that Bayeux may not be long lived and that better protocols will emerge. That may be so, but if Bayeux is successful in weaning developers off XHR (and wrappers), of getting them thinking of messaging (instead of request/response), and of separating transport concerns from the application, then Bayeux will have done its job. I dare say that to transition to some Bayeux-killer will be almost trivial once XHR is dead and transport is no longer specified in magic headers and parameters buried deep within an application’s business logic.

Bayeux makes no claim to being the end of the road on Comet evolution. Just to being a big step in the approximate right direction, and to having low entry barriers so that it does not need to affect your choice of language, server, framework etc.

6 Responses to “Colliding Comets: Battle of the Bayeux Part 3”

  1. Patrick Myles Says:

    Great series of articles, both of you!

    I largely agree Michael’s point of view on this, but actually feel that less than the full stack is needed right now. In fact, I think only the App / Protocol Layer is required.

    I really like the idea of standardised pub/sub and/or messaging APIs for comet applications, but I’m quite against standardised transports…

    I don’t see why Bayeux should dictate the transport (which as far as I am concerned, it does, even though Greg states: “Bayeux specifies that transport is negotiated between a client and server and that the details of that transport are a separate concern to the use of the Bayeux messaging layer.”). Similarly, in your reply Michael, you start with the proposition: “As Comet takes off over the next couple of years, the single most important action we can take is to standardize communication between Comet servers and clients.”

    I disagree. I think that having a standardised API for bi-directional comet messaging is much more important than the standardisation of the communication (transport) piece. Yes, this may impose restricitions on the transport protocol chosen for implementation, but that’s more a side-effect of the constructs and concepts of the API layer.

    Surely if we have a well designed, abstracted messaging API and associated concepts, then the details of the transport is up to the implementation. You still get interoperability between different Bayuex implementations at the messaging API level, and the server vendor provides the implementation and client-side JavaScript API.

    As a vendor ( of a comet server / client implementation, this seems the logical approach for us to embrace. Part of our differentiator in the market is the efficiency and resiliance of our transport layer - it would be a shame to lose this additional capability by conforming to a lowest-common-denominator transport. Similarly, if in the future the transport mechanisms such as flex data services, silverlight, (or anything else that might come along) prove to be a more appropriate solution, then the transport layer can be replaced with minimal impact to the client-side user code.

  2. Kris Zyp Says:

    Greg, you seem to suggest that a subscription can be made with two requests (when starting), a handshake and a subscription request. However, the Bayeux proposal seems to require three requests, a handshake, a connection request, and a subscription request.

    Patrick, the importance of communication standardization vs API standardization is a classic debate that spans more than just Comet. In the world of cross-site data reqesting, the same questions apply. I think we would do well to not presume that one way is the cure-all for all situations. Both communication standardization and API standardization are both important. API standardization provides the means for technology such as your to utilize more efficient techniques while still adhering to standards, while a communication standards allows a single client code to interact with different servers without requiring new communication handlers. The OpenAjax alliance has mainly focused on the API side of things (maybe too much in my opinion, but it is certainly good that it is happening).

  3. Michael Carter Says:

    @Patrick: You missed the other debate about communication protocol vs. api: . I do agree with you that the api is very important — I should have started my post off with “the single most important action we can take is to standardize either the client api or communication between Comet servers and client.”

  4. GregWilkins Says:


    The connection request is not part of a subscription, but part of the fetching messages. So the additional cost of having a subscribe based architecture is at most 2 requests at startup. In reality it is less, because 1 request is really for transport negotiation and a subscription can be batched with other subscriptions or even the first connect request.

    But I think the main point of contention remains should we be striving for a API standard, an protocol standard, both or neither. Now if we could all agree on an API or on a protocol, then I indeed think that they would be a fine thing to have. But getting such an agreement is going to be very hard thing to achieve, specially at this early stage in the technology where we are all still learning and adapting.

    So Bayeux has taken a loose pragmatic approach. It has standardized semantic instead of a standardized API - this may eventually lead to a standardized IDL of and API and indeed there is collaboration already between tomcat and Jetty to move our server side APIs closer together.
    It has specified transport negotiation and content without nailing down an exact transport.

    This looseness is Bayeux strength! If we had been aiming for complete standardization, we would not today have implementations in dojo, jquery, flash, ext, java, jetty, weblogic, tomcat, etc etc. You can implement Bayeu, innovate and still get a good degree of interoperability or at least portability.

  5. Peter Saint-Andre Says:

    As co-author of the BOSH specification, I’d be interested in helping out with any protocol specifications that emerge from these discussions. Is there mailing list or other forum where the protocol is discussed? I don’t see a venue mentioned in the Bayeux spec.

  6. DylanSchiemann Says:

    I believe such discussions would normally happen on the Cometd mailing list. I’m not sure if the dev list or users list is the more appropriate forum.

Copyright 2015 Comet Daily, LLC. All Rights Reserved