It is a key point that Couch raises and I am working with Coach within the Open Ajax Alliance to explore the possibility of a more standard messaging base for web-2.0.
It will be a difficult problem, as we have been taught that the path to Ajax is XmlHttpRequest and most Ajax communication frameworks are based on that API.
But XmlHttpRequest allocates a scarce resource (a HTTP connection) for the duration of a request. Browsers only allow two connections to a given host. The moment you have multiple windows, tabs, frameworks or components using XmlHttpRequest, there is going to be contention for connections, resulting in blocked and inefficient communications.
The pity is, that 2 HTTP persistent connections are sufficient for efficient two way communication, but only if the multiple windows, tabs, frameworks and components can share connections nad multiplex and/or batch messaging over them.
Increasing the limit is not an option as web-2.0 comms is already stressing a server infrastructure designed for web-1.0 and more round trips to the server is not what we need to improve interactivity.
I hope the open ajax alliance hub will be able to provide some APIs to facilitate sharing connections between frameworks and components, but browser support will be needed to share between windows and tabs.
For the actual protocol to be used, there are many many
candidates: REST-ful, JMS, cometd from DOJO, beep, sip, jabber, the list is endless. I have developed or contributed to implementation for several of these (beep, activemq, DWR, and cometd) and all have their benefits and all can be well transported over HTTP.
However, I do not think the solution is in picking a winner among protocols. I think the solutions is recognizing that the paradigm for Ajax communication is messaging and not raw HTTP Request. A common messaging API in the browser would allow multiple protocols to be tried and tested. New protocols can be developed and eventual browser/infrastructure support may even take us away from HTTP. The Open Ajax Alliance can certainly provide this common API and then we can all innovate above or below that API.