HTML5 in the browser: HTML5 data communications
Cross-document messaging, WebSockets, and other HTML5 APIs bolster website and browser interactivity to create a faster, richer WebFollow @peterwayner
The API does arrange for communication to be limited to specific domains. It's not possible to broadcast messages to all listeners who might want to receive them. They need to be targeted at windows of particular documents. For sustained communications, a specific channel can be created to act like a two-way pipe.
The details aren't final by any means, and programmers should be wary. Although Chrome, Firefox, IE, Opera, and Safari all implement the feature and let you create the listener objects, the draft of the API spec contains a warning: "Implementors should be aware that this specification is not stable."
At this point, the paradigm is well understood because many UI programmers use a similar model to structure the way that an application communicates with itself and its many parts. The changes probably won't affect the basic model of listener and event, but the details are still being worked out. To see how your browser handles cross-document messaging, point it to my cross-document messaging test page.
Cross-origin resource sharing
Sending messages is not the only solution for sharing information between different websites. The cross-origin resource sharing API loosens the controls over AJAX calls to anywhere but the home domain. A website can specify a list of allowable targets, and the
XMLHttpRequest calls will just work -- at least, they should.
The information is bundled in the header of the document, which places it a bit out of reach of the average HTML coder. The server itself must be reconfigured to include parameters like these:
Access-Control-Allow-Origin: http://infoworld.com Access-Control-Max-Age: 10000 Access-Control-Allow-Methods: PUT, DELETE
Any website that receives this will be able to put and delete data from InfoWorld.com for all of 10,000 seconds. The original website, in essence, is giving the software the permission to call up someone else for extra data. The deadline may be useful for closing out sessions and blocking access when people inadvertently leave windows open.
When AJAX calls take a long time to complete, they traditionally fail with a time-out. This may be acceptable for basic tasks like collecting the latest headlines, but the eventual time-out makes it a bit trickier to implement interactive websites. Developers have traditionally worked around the problem by polling the server frequently.
The WebSocket API is an attempt to avoid all of the constant browser reconnections by digging deeper into the TCP stack to allow connections that stay up waiting for information to return. When the
WebSocket object is implemented, functions are created for listening for new data with the
onmessage field. Data can also be sent to the server when necessary.
Do the connections really stay open? Ha! This is the Web we're talking about, a world where ISPs still routinely promise "unlimited" data transfer over 25Mbps links -- honest, promise. Programmers need to assume that the connection will fail from time to time, even though it will stay open long enough to save the need for constant polling.