Wednesday, July 26th, 2006
Adding on to the last post on cross domain XHR, Cometd now supports working across domains, without plugins.
Alex Russell explains:
By building on top of the Dojo ScriptSrcIO infrastructure it was trivial to make a JSONP transport for Cometd. We just adapt the long-poll style of Comet but make the initial handshake messages JSONP-clued. That in place, the rest works just like â€œnormalâ€ long-polling, except that the client can connect from any domain. The configuration problem just dropped from â€œmake sure everything cooperates at the systems and network levelâ€ to â€œmake sure that the client and server speak the same protocolâ€â€¦and I like solutions that put the problem in software and not external configuration or human effort.
So whatâ€™s the downside? The first downside is that the latency characteristics for cross-domain Comet using this technique are the same as long-polling. Not bad, mind you, but not as optimal as iframe, multipart-mime, or Flash-based solutions when you have large numbers of messages being thrown at the client. Additionally, itâ€™s more difficult to know when a connection â€œtimes outâ€ or in some other way fails, but I think these are tractable. Having a Plan A and a Plan B for cross-domain Comet and a server that can speak both styles via pluggable transport wrappers is exciting to me. By lowering the configuration barrier, I think weâ€™ll start to see a significant uptick in Comet adoption.
Posted by Dion Almaer at 9:42 am