Michael Carter says that his concerns about the Bayeux protocol have gone unanswered, and that Greg Wilkins’ and Alex Russell’s arguments for Bayeux have focused on peripheral issues.
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
I’ve already made clear, technical arguments about Bayeux’s flaws, but those issues still haven’t been addressed. In his original article, Greg brought up multi-frame connection sharing as one of Bayeux’s core features, and in an effort to keep the dialogue centered on facts I pointed out that Bayeux actually doesn’t solve the problem whatsoever. Alex, on the other hand, has a different opinion on the matter. But while Greg is claiming that Bayeux’s strength is that it supports connection sharing, and Alex is proclaiming that actually it’s the lack of that support that is the real strength, let me say that I honestly couldn’t care less about multi-frame anything; a proposal to solve this was in the works long before I even entered the realm of Comet development. There are so many more important issues.
Bayeux is a bad foundation for Comet communication. It implies the wrong API, and by not specifying an actual API, an application can’t swap one Bayeux client out for another. It lacks any message reliability or ordering guarantees. There is no standard way of integrating new transports—that’s completely unspecified. The worst part is that these flaws are, according to Alex, not errors of omission; rather, they are by design. The Bayeux authors don’t care about client interoperability or transport interoperability, which are the only two parts of Comet that are even possible to standardize. Instead they’ve chosen a communication protocol (note my previous musing that lacks many necessary features, demands the use of publish/subscribe messaging, and will almost certainly be obsolete within the year, when long-polling, the “critical core” of Bayeux, goes out of style.
On the other hand, the API for bi-directional communication has been known for more than forty years. It’s a socket, and it supports open, close, send, and receive. Long polling happens to be one way to implement the receive method, and as Alex suggests, it’s far from the best. We already know we want nothing to do with the current methods of communication a few years down the line, so let’s stop trying to standardize a communication protocol and instead choose a good API. Why on earth would we have to hem and haw on the ideal standard Comet API when it’s so clearly a TCP Socket, and in fact already defined in HTML5? I say, declare the TCPConnection as the base for Bayeux’s communication and be done with it. When all the browsers support bi-directional communication, preferably via the actual TCPConnection specification, then we can throw out all the hacks and get on with our life. And in the meantime, the rest of us aren’t saddled with the publish/subscribe layer that’s a useless burden to many applications.
Of course, Bayeux also tries to allow interoperability between an arbitrary client and server. I detailed previously exactly why I think that this is absolutely the wrong target for public standardization, because the important interface is between applications developers and a Comet implementation, not between Comet servers and clients. That said, we would do well to have our own APIs and even protocols that allow us to share client side code. In particular, we need a Comet transport API that defines a simple interface for connecting to a remote server, identifying the connection to that server, and receiving data. It also makes sense to allow an implementation of this API to specify an upstream communication mechanism. A Comet client would really just be an implementation of a TCP socket built on top of the Comet transports. If Orbited defined a fast new Comet transport, anyone’s Comet TCP implementation could use the code without modification.
The story I’m outlining for interoperability is that your browser-side application includes a comet.js from the Comet server, which exposes the TCPConnection API. If you want a new Comet server, just start it up and link to that new server’s comet.js file. In the end, the interface is always the same. If developers want publish/subscribe, then they can use Bayeux, which would be built on the TCPConnection interface. This is the ideal world for application developers, and even for the Bayeux authors who want to push a particular mode of interaction for Comet. They can worry about publish/subscribe but have a reasonable communication layer. This would work out well for server developers too, as we would probably end up sharing much of the comet.js code that implements the transports and protocol necessary to expose the proper interface, but we wouldn’t muddy the waters for the general public—they’d just have a single interface to worry about. In the end, we’ll get some kind of native TCP connection in a browser, and suddenly Comet is irrelevant, and our applications continue to work, but even more efficiently.