Transfer of Control to an Applet

Every event that leads to sending an HTTP request (such as clicking on a hyperlink or parsing a reference to an embedded image) needs to be intercepted by the Web++ applet in order to bind the logical URL to one of the physical URLs embedded in the resource. We found two possible solutions:

• Let the browser itself render every resource along with the necessary graphical controls (e.g. ``Back'' button). Since the applet itself renders all graphical elements, it is simple to intercept all of the important events.
• Add JavaScript event handlers into the HTML source. The event handler transfers control to the Web++ applet when the events occur.

The first solution leads to a duplication of the browser's functionality within the Web++ applet. We rejected this solution because, in general, duplication of code is a poor software engineering practice. In this specific case, it would be difficult to keep the applet rendering capabilities in sync with the latest version of HTML implemented by browsers. We therefore adopted the second approach that does not lead to any functionality duplication. However, due to the limitation of the java.applet API, not all important events can be intercepted by the applet. We discuss these cases below.

The HTML source modification is performed by the Web++ server. The server expands each reference to a logical URL in the resource (which typically follows <HREF> or <SRC> HTML tags) with an invocation of a JavaScript event handler. The event handler updates the value of the hyperlink reference when the hyperlink is clicked upon. For example, the hyperlink

<A href="/legacy/misc/file.txt"> 

is replaced by the server with

<A href="/legacy/misc/file.txt"  
onClick="this.ref = 
document.Webpp.getUrl( 
https://server1.com/files/miscFile.txt, 
https://server2.com/misc/file.txt)">  

References to embedded resources (following the <SRC> HTML tag) are expanded in a similar manner. On browsers that do not support JavaScript, the onClick event handler is ignored and the supplied URL is used instead. Therefore, it is beneficial to select the logical URL to correspond to one of the physical URLs, e.g. the physical URL of a primary copy.

The parameters passed to the applet method directly correspond to an entry in the replication directory of the server. The above method of including the list of physical URLs directly into the HTML source may lead to an increase of size of the resource that must be transmitted to the client. However, it is possible to put all the binding information into a new HTTP header, which is then read by the client applet. Standard compression techniques can be applied on the content of the header to reduce the size of the transmitted data. The compression may be particularly effective if many of the resources are replicated on the same set of servers leading to a high redundancy in the header content. We are currently in the process of implementing the above optimization and evaluating its impact on the performance.