next up previous
Next: Java: Code Downloading Up: Distributed Communication Previous: X: Network I/O

Web Browsers: High-Level Network I/O

So what we would like is a higher-level I/O package that, like X, is portable and offers a network interface.

A Web browser [], in fact, is such package. It is not a typical "I/O package" in that a remote process does not execute output procedures to display information, instead it sends documents or pages describing the display layout in HTML (HyperText Markup Language). An HTML document is stored at any internet site and is managed by an HTTP (Hyper Text Transfer Protocol) server at that site. It is associated with an internet-wide name called URL (Universal Resource Locator), which identifies the server managing it. A browser can request a document from any server by sending it the URL of the document.

An HTML document may include a directive to periodically load a particular page. More important, it may display not only hyperlinked static text, but also dynamic forms for sending input to remote procedures. A form contains interactors (or widgets) such as text items, menu choices, sliders, and nested forms for entering input values. It is also associated with a remote callback called a CGI (Common Gateway Interface) script. The script is invoked when the user submits the form and receives as parameters the input values entered in the form. In response, it sends the browser an HTML document describing the new display. A CGI script is associated with a URL and is executed by the HTTP server that manages it.

There are, of course, many flavours of browsers and servers, but all of them must support the currently accepted HTML and HTTP, respectively, though they can provide their own extensions. Of particular interest to use are browsers that provide a CCI (Client Communication Interface). Such an interface, typically, allows some other, possibly local, process to both monitor and invoke actions of the browser such as loading of a new page.

Centralized Example: We define an HTML document for the application, whose URL serves as the session name. Users join the session by loading this document in their browsers. The document displays a form containing a text item showing the greeting. A users may edit and submit the form to change the greeting. The CGI script invoked to process the form changes the greeting field in the HTML document and asks the browser to reload this page.

How do other users view a change to the greeting? The simplest approach is for user to explicitly reload the document to see the current value. Instead of making the user poll for the new value, we can specify in the document that the browser should automatically poll for it. These are essentially the user-interfaces we saw in the repository-based solutions. Implementing a non-polling interface is more difficult but possible if the browser provides a CCI interface. At the server site, we create a session process responsible for notifying browsers of changes to the HTML document and monitoring its loads. (If CCI allows only local processes to talk to a browser, then we need to create, for each browser, an additional local process connecting it to the session manager.)

as that user's surrogate. When a browser first loads the HTML document, the session manager registers it in a directory. The CGI script now, in addition to changing the document, also informs the session manager about the change, which then

asks all the registered browsers to reload the page.

This approach to implementing a centralized application offers several advantages over the X-based one. A web browser does higher-level processing of I/O, thereby requiring less communication with the remote master process. In our example, it provides local processing of scrolling, backspace, and other browser commands, sending and receiving only the greeting string from the master. Moreover, support for URLs automates session naming.

The browser also provides a standard user-interface for interacting with applications. Furthermore, we can use a single set of physical windows created by a particular instance of the browser to interact with and navigate among multiple application. Perhaps most important, Web browsers are more portable than X in that everyone (including Microsoft!) has ported it. A directory of HTML documents can also be associated with access lists describing the list of authorized users and their passwords. Since an HTML document is stored as a file in the native OS, all file-based collaboration functions such as concurrency control can also be used, but these are OS-specific and thus would not be portable. Thus, we get can combine some of the benefits of schemes based on repositories and distributed communication.

On the other hand, this approach is far from ideal for developing general collaborative applications. The access-control provided by it is very coarse-grained, it only decides who can access the document without distinguishing between different kinds of accesses such as read and write. Finer-grained control must be implemented by the CGI scripts. More important, users cannot receive incremental feedback to (local or remote) input, since a form is processed when it is submitted and not as users make changes to it. For instance, in our application, users cannot see incremental changes to the greeting made by their collaborators. Conversely, this approach does not work well when a CGI script needs to make an incremental change in the display, since a whole new document describing the complete display must be sent to the browser and processed by it, which makes the interaction slower and causes the display to flicker. (Current browsers do not calculate the diffs between the original and new dispays). Since a browser is a high-level I/O package, it cannot create arbitrary user interfaces.

The non-polling solutions are far from ideal since the session manager and user agents must be coded using some IPC mechanism, and perhaps more important, a large number of processes are involved in the communication of information from a local user to a remote user: the local browsers, the HTTP server that receives the CGI request, the copy of the server forked to execute the CGI script, the session manager, and finally, the remote browser.

Moreover, if the CCI supports communication among local processes, then an additional local process would be involved. In the X-based solution, only three processes are involved: the host and the local and remote X servers. If the browsers are implemented on top of X, then the two X servers would still be involved in the communication.



next up previous
Next: Java: Code Downloading Up: Distributed Communication Previous: X: Network I/O



Prasun Dewan
Sun Mar 16 14:09:55 EST 1997