Cross-document messaging The HTML5 team is pushing the idea of cross-document messaging or communications. This would let the different rectangles set up a communications path by creating listeners that wait dutifully for message events from other rectangles. There's no need to run through a central server. The code just packs up the messages and sends them to some listener. It's a little like one neighbor talking to another by tying the message to a rock and throwing it over a fence. Good fences make good neighbors.
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.