Couch Wei’s blog talks about the need for a web-2.0 messaging layer. See also the follow on discussion on the
The server side.
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.
In the meantime, I strongly suggest looking towards activemq Ajax or dojo’s cometd for your Ajax-2.0 communications. Messaging is where it is at!
Categories: GeneralUncategorized
4 Comments
Anonymous · 19/10/2006 at 05:59
Am I confused, or is what you are describing can be implemented today in, say, XPCom and will work with Mozilla (giving
mozilla AJAX apps that extra oomph that will in turn improve
mozilla’s popularity? 🙂
Greg Wilkins · 19/10/2006 at 21:33
XPCom and a many other solutions exist for doing Ajax communications. But currently anything that is true Ajax (ie against the standards and does not need browser plugins) will hit the 2 connection limit. To facilitate inter-operability, some level of cooperation is needed between the frameworks so that connections may be shared. To facilitate multi-tab/window usage, some extensions are needed in the browser.
Anonymous · 31/10/2006 at 05:49
Please recheck your links, some are broken with http://http:// links.
Thanks!
Jan Bartel · 06/11/2006 at 00:45
Broken link now fixed.
Thanks.
Comments are closed.