Joy's Blog

Current Web browsers weren't designed to easily and securely get content from multiple sources into one page. This article discusses about how developers have stretched the available tools to fit the task and how doing so has put strain on the resulting applications with respect to security and scalability. Also, several browser improvements being proposed to remedy the situation has been discussed that will bring Web development beyond this hurdle to a new level of interoperability.

Dynamic HTML (DHTML) was not initially used in combination with dynamically retrieved content. Both the presentation and data elements of a dynamic Web page were delivered together along with scripts to manipulate them. Data flow was synchronous with page reload.

Consequently, developers who wished to build the kind of hybrid Web application that we now call a mashup had to take the available technology and find ways to stretch it to fit their needs. Two approaches were taken to allow the browser to retrieve content without reloading the page: embedding an external transport mechanism and using browser-native objects to perform transport duties.

An early solution was Microsoft's Remote Scripting, which used a Java™ applet that exchanged XML-formatted messages with server-side components. This approach quickly became unwieldy because of vendor squabbles as well as Java Virtual Machine (JVM) and security model differences.

Microsoft later built the XMLHttpRequest (XHR) object, whose designers had the expectation that it would be used only with Microsoft® Outlook® Web Access (OWA). The object was initially available only to Windows® Internet Explorer® users and subsequently not widely used until years later, when Mozilla and Safari adopted it. Originally an external Microsoft ActiveX® object, current implementations are native objects within the browser. Despite its name, the XHR object can transfer data in any format and is not limited to valid XML.

Because of the problems and dependencies associated with external transport mechanisms, the internet development community has collaborated in the discovery and development of several browser-native remote calling methods.

* Using a hidden iframe element to load external content: The iframe is then accessed through the DOM to extract the content from the document it has loaded. You can specify any parameters in the URL querystring or dynamically create a form that posts to the service with the iframe as a target. This method is compatible across a wide range of both current and older browsers.
* Using an img element to send requests for content: The server performs its task using the parameters from the URL's querystring, and then returns encoded content in a cookie. This method is limited in the amount of data that can be easily communicated, because both querystring and cookies are limited in size.
* Dynamically creating a script element in the DOM of the current page: Upon loading, code that the server supplies is immediately executed. The server uses parameters from the URL querystring.

Potential Solutions

A more recently developed content-retrieval technique employs communication between a page's script and a hidden iframe through its src URL's fragment identifier (the part of the URL that comes after the # sign). Scripts in the parent page and embedded iframe can set each other's fragment identifiers despite coming from different origins. An agreed-upon communication protocol is maintained between the scripts, driven by JavaScript timers that periodically fire routines to check for changes in the fragment identifier.
Because the scripts must know each other's addresses and they must collaborate between themselves to agree on a protocol, trust is ensured. Because any server interaction is local to each component and separate from the inter-script communication, cookies are not exposed.

Long term
Browser manufacturers and the development community are currently discussing several potential ways to modify elements of the browser environment to make it purpose-built for Ajax mashups. The Web Hypertext Application Technology Working Group (WHATWG) has a proposal in section 7.3 of its Web Applications 1.0 Working Draft for a mechanism called Cross Document Messaging. The Opera browser already implements this feature. It specifies a method of collaborative communication between DOM objects from different domains that allow the receiver of a message to choose which messages to respond to based on their origin.

Here are some proposals:
1. Cross-site extensions to the existing XMLHttpRequest object. The proposal consists of several modifications to the way requests are made, including restrictions on header control and an access-control mechanism.

2. Another proposal is JSON, a data-interchange format that is widely used in Ajax applications, primarily because it is readily parsable by JavaScript and less verbose than XML.