The World Wide Web has matured from a relatively limited system for passive viewing of hypermedia-based documents into a robust framework for interactive application development and delivery. Much of this progress is due to the development of embedded executable content, also known as "inline Web applets," which allow Web pages to become full-blown, compound-document-based application environments. The first Web-based applets resulted from research begun in the late 1980s to find a low-cost way to provide widespread access for scientists and educators to remote, supercomputer-based visualization systems.

In the late 1980s, the National Library of Medicine began a project to create a "standard" database of human anatomy. This "Visible Human Project" was to comprise over 30 GB of volume data on both male and female adult human anatomical structures. It was one of the original Grand Challenge projects in the federal High-Performance Computing and Communications initiative, the brainchild of then Senator Al Gore. As a member of the scientific advisory board for this project, one of us (Michael Doyle) became interested in the software issues involved in working with such a large database of the most detailed image information on human anatomical structure yet available. His group in the Biomedical Visualization Lab (BVL) at the University of Illinois at Chicago realized at the time that much research would have to be done to make such a vast resource both functional and accessible to scientists all around the world.

Until that time, medical visualization systems were designed to work on 3-D datasets in the 15-30 MB range, as produced by the typical CT or MRI scanner. High-end graphics workstations had adequate memory capacity and processor power to allow good interactive visualization and analysis of these routine datasets. The Visible Human data, however, presented an entirely different set of problems. To allow widespread access to an interactive visualization system based upon such a large body of data would require the combined computational power of several supercomputers, something not normally found in the typical biomedical scientist's lab budget.

Doyle's BVL group immediately began to work on solving the information-science problems related to both allowing interactive control of such data and distributing access to the system to scientists anywhere on the Internet. Our goal was to provide ubiquitous access to the system, allowing any user connected to the Internet to effectively use the system from inexpensive machines, regardless of platform or operating system.

We saw Mosaic for the first time when Larry Smarr, director of the National Center for Supercomputing Applications, demonstrated it at an NSF site visit at BVL in early 1993. We became immediately intrigued with the potential for Mosaic to act as the front end to the online visualization resource we had been designing. Immediately after Michael Doyle left the University of Illinois to take the position of director of the academic computing center at the University of California, San Francisco, we began enhancing Mosaic to integrate it with our system. We designed and implemented an API for embedded inline applets that allowed a Web page to act as a "container" document for a fully interactive remote-visualization application, allowing real-time volume rendering and analysis of huge collections of 3-D biomedical volume data, where most of the computation was performed by powerful remote visualization engines. Using our enhanced version of Mosaic, later dubbed "WebRouser," a scientist using a low-end workstation could exploit computational power far beyond anything that could be found in one location.

This work was shown to several groups in 1993, including many that were later involved in projects to add APIs and applets to Web browsers at places such as NCSA, Netscape, and Sun. Realizing our group's work enabled the transformation of the Web into a robust platform for the development and deployment of any type of interactive application, in 1994 the University of California filed a U.S. patent application covering embedded program objects in distributed hypermedia documents. Eolas Technologies was then founded by the inventors to promote widespread commercialization and further development of the technology.

Once the concept of the Web as an environment for interactive applications was initiated, the question was how to further develop it. Toward the end of 1993, we discussed the relative merits of building an interpreted language, such as Basic or Tcl, directly into the browser versus enhancing browsers through a "plug-in" API. We chose the API approach, believing that the best way to add language support would be by adding interpreters as external inline plug-in applets, which we called "Weblet applications." This would enable us to add a new language or other feature merely by developing a new Weblet application, without having to reengineer the browser itself.

Our general philosophy with WebRouser was to allow enhancement of the browser's functionality through object-oriented, modular application components that conform to a standard API, rather than turning the browser into a monolithic application with an ever-increasing code base. This encourages Web developers to take a document-centric approach to application development. The Web page itself becomes the mechanism for doing work, through collections of small, efficient Weblet building blocks, rather than the menagerie of top-heavy applications found on the common desktop PC.

The first release of WebRouser also included other enhancements aimed primarily at improving the interactivity of Web pages. These included client-side image maps, a document-driven button bar, and document-driven modification of the browser's menu tree.

Client-side image maps are supported through the Polymap format. Polymap files are essentially GIF files with polygon and URL information stored in the image's comment fields. To prevent complex polygon information from bloating the file, all of the comment fields are compressed and decompressed using the GIF LZW algorithm. Polymap files require no special treatment of the HTML code. WebRouser autodetects the presence of Polymap data when it reads inline GIFs. If a server-side (ISMAP) image map points to a Polymap GIF, then WebRouser will ignore the ISMAP data and give the Polymap data priority. Hotspots are decoded in real time and highlighted as the mouse moves over the image, and the associated URL is displayed at the bottom of the screen, providing users the same style of interactivity that hotwords have in HTML text. The Polymap format specification is open and freely available for use. You can find the spec at http://www.eolas.com/papers/Papers/Polymap/.

Of course, the key feature of WebRouser is the implementation of the <EMBED...> tag, through which inline plug-in Weblet applications are supported in Web pages. X Window applications that conform to the Eolas distributed hypermedia object embedding (DHOE) protocol can run--inline and fully interactive--within Web pages in the WebRouser window. WebRouser also supports the NCSA common client interface (CCI), which allows the Weblet to "drive" the browser application. DHOE and CCI collectively make up the Eolas Web API (WAPI) as supported in WebRouser.

WAPI is minimalist, combining the functionality of DHOE and CCI to exploit both the efficiency of X-events for communication of interaction events and graphic data and the flexibility of socket-based messaging for browser remote control and HTML rendering of Weblet-generated data. We are currently working on a cross-platform API, in the form of an OpenGL-style common-function library. The current minimalist WAPI specification will allow us greater flexibility in creating a cross-platform API, while maintaining compatibility with Weblets developed under the UNIX WAPI specification.

Eolas' primary objective with respect to the pending Web-applet patent is to facilitate the adoption of a standard API for interactive, Web-based application development, and then to develop innovative Weblet-based applications for the growing Internet software market. For an example of such a Weblet application, see the accompanying text box entitled "WebWish: Our Wish is Your Command." We intend to short circuit the API wars brewing between the major Web-browser competitors. In addition to creating a universal standard API, we are also instituting a mechanism for ensuring continued evolution of the WAPI spec on a regular timetable. Royalty-free licenses for browser-side implementation of Web applets under the pending patent have been offered to the major browser companies, and are in various degrees of negotiation. The primary condition of these licenses is that each licensee must conform to the WAPI protocol, and no other applet-integration protocol. A consortium of Eolas licensees is being formed to set the continuing WAPI specification and update it at regular intervals. The widespread acceptance of the developing WAPI standard will allow application developers to concentrate on the functionality of their applets without worrying which Web browser their customers will use.

WebRouser communicates with Weblet applications through a set of messages called the DHOE protocol. DHOE messages are relatively short character strings, which allow convenient, efficient use of existing interprocess-communications mechanisms on various platforms. We have implemented DHOE systems on several X Window platforms, including IRIX, SunOS, Solaris, OS/F 1, Sequent, and Linux. Implementations for both Microsoft Windows and Macintosh are planned for release by the end of the first quarter of 1996.

WT is an applet that allows interactive rotation and zooming of a 3-D CAD file stored in NASA's neutral file format (NFF). The source code for the sample Weblet application is available electronically (see "Availability," page 3) and at http://www .eolas.com/eolas/webrouse/wtsrc.tar.Z. What follows is a brief walk-through of the weblet-enhancing sections of the code (illustrated in the code listing just mentioned as a "simplified sample program outline").

1. The outline starts with a typedef and some global declarations. The new type, ApplicationData, defines a structure common to all Xt Weblets. Together with the myResources and myOptions static variables, myAppData (which is of type ApplicationData) is used with XtGetApplicationResources in main() to extract the command-line arguments flagged with win, pixmap, pixmap_width, pixmap_height, and datafile. This is how Xt extracts command-line arguments and is unnecessary if the program has alternatives to decode command-line arguments. The aforementioned global variables and XtGetApplicationResources nicely store the information in a line such as wt -win 1234 -pixmap 5678 -pixmap_width 400 - pixmap_height 300 -datafile fname into myAppData.

2. In main(), app_shell is first initialized the Xt way by using XtInitialize, which opens a connection to the X server and creates a top-level widget. XtGetApplicationResources gets the application resources as in step 1. The next section conveniently uses the myAppData.win variable to find out if the Weblet should run as a DHOE server or a stand-alone program. For a DHOE server, the program adds the handle_client_msg function from the DHOE implementation, protocol_lib.c, as the handler of the X client message event. The subsequent lines call three more DHOE functions: register_client, to initiate a handshake with the DHOE client; register_client_msg_callback, to register myQuit() as the callback function of the message XtNexitNotify; and send_client_msg, to send a XtNpanelStartNotify message, telling the DHOE client that the server is ready. The program then enters the conventional XtMainLoop().

3. Two more functions must be modified. The drawing routine (myDraw) needs to copy the drawn picture (myPixmap in this case) onto myAppData.pixmap, the client's pixmap. The function then should send an XtNrefreshNotify message to the client, informing it of the change. The myQuit() function registered in main() needs to send an XtNpanelExitNotify message to the client, telling the client that the server is terminated.

This Weblet can be tested by putting it in your path and pointing your copy of WebRouser to http://www.eolas.com/eolas/ webrouse/office.htm.

In addition to the WebWish applet described in the text box, a Java interpreter Weblet application is planned for release by the end of March 1996. Java is a compiled language that produces binaries for a "virtual machine." The binaries are downloaded to the client and run on virtual-machine emulators that run on Macintosh, Windows, and UNIX platforms. Java applications tend to be smaller and more efficient than WebWish interpreted code, but they are far more difficult to develop. Eolas is developing a virtual operating system, the Web OS (planned for release late in 1996) that will allow far more robust, compact, and efficient compiled applets to be developed than is possible with Java. The Web OS is key to Eolas' long-term goal to transform the Web into a robust, document-centric, distributed-component application environment. It is a real-time, preemptive multitasking, multithreaded, object-oriented operating system that will run efficiently on low-end platforms, even on 80286-based systems and handheld PDAs.

The Web OS can run within Windows, Macintosh, and UNIX environments, or in stand-alone mode on machines with no pre-installed operating system. It supports dynamic memory management and linked libraries, and is both graphical and object oriented at the OS level. The OS kernel includes fully defined object classes, inheritance, and direct messaging. The OS includes several building-block objects that allow sophisticated applications--WYSIWYG word processors, spreadsheets, databases, e-mail systems, and the like--to be developed with a minimum of code. These applications are created primarily by subclassing and combining various Web OS component objects. Since new applications are created by defining differences and additions to the constituent objects, this results in tiny, robust, efficient binaries that optimize both bandwidth usage and server storage requirements. This platform is so efficient that a complete WYSIWYG word processor can be created in less than 5K of compiled code. Applications developed for the Web OS are likely to be smaller than most of the inline GIF images found on average Web pages today.

The operating system employs a single imaging model for screen, printer, fax, and other output devices; an installable file system, for both local and remote file access; direct TCP/IP and socket support; distributed objects; and security through public-key encryption and "ticket-based" authentication.

As the Internet pervades more of our work environments, the Web OS will allow the Web to become the preferred environment for new and innovative productivity, communications, and entertainment applications for all hardware platforms. The concept of a machine-specific operating system will become irrelevant, since any application will be available to the average user, regardless of hardware platform. Much of the computational load for applications will be pushed off to remotely networked computational engines, allowing low-cost Web terminals to act as ubiquitous doorways to potentially unlimited computational resources. The Web will be your operating system and the Internet will be your computer.

WebWish: Our Wish is Your Command

Sun's announcement of the adaptation of the Java language to the Web in 1995 was received enthusiastically by the entire Internet community as a welcome means for increasing the interactivity of Web-based content. Despite much of the publicity surrounding Java, which described it as an "interpreted" language, Java code must be compiled to a "virtual machine," which is then emulated on various platforms. A Web browser that supports the Java emulator is not enough to develop Java-based applications--the applet developer must purchase a compiler from Sun or its licensees at considerable cost.

Fully interpreted languages like Tcl/Tk or Basic are extremely useful, partly because they don't require a compiler for application development, just the language interpreter and any ASCII text editor. In choosing a programming language to adapt to the Web API, we decided early on that a fully interpreted programming language would be vital to quick, widespread Weblet implementation. We chose Tcl/Tk because of its robust capabilities and widespread use.

By the time you read this article, Eolas' WebWish Tcl/Tk interpreter should be available for both WebRouser under UNIX and Netscape Navigator 2.0 on Windows and Macintosh (see http://www.eolas.com/eolas/webrouse/tcl.htm). It supports Tcl 7.5 and Tk 4.1, as well as the Tcl-DP and EXPECT extensions. A new security feature has been added that exploits PGP-style digital signatures in order to authenticate scripts from trusted sources and to prevent unwanted execution of scripts from untrusted sources. This Weblet application turns WebRouser and Navigator into complete application-development environments, without the need for expensive compilers. All that is needed to develop a WebWish-based application is WebWish, a WAPI-compliant Web browser, and a good text editor. Developers can draw upon the vast existing resources of freely downloadable Tcl/Tk program source code, and the expertise of thousands of experienced programmers.

WebWish provides an easy-to-use rapid prototyping environment, with built-in support for socket-based communications, remote procedure calls (RPCs), and the ability to "remote control" existing text-based server systems without reengineering the server. WebWish can run either as a Weblet in a Web page, or in stand-alone mode on either the client or a server machine. WebWish running in a Web page can communicate directly with other copies of WebWish running on remote servers, either through sockets or RPCs. This allows WebWish to act as "middleware" for the Web, allowing Web-based interfaces to create state-aware graphical front ends to existing text-based legacy systems, without changing the operation of the legacy-server application.

Last November, Chicago's Rush Presbyterian St. Luke's Medical Center surgical department created both client and server WebWish applets for just such a purpose. The applets allowed physicians using WebRouser to interactively query and browse Rush's (Informix) SQL-based Surgical Information System, consisting of medical records on over 1.5 million patients. The entire project took one programmer exactly 12 hours from start to finish. Try that with Java!

--M.D., C.A., and D.M.

<GROUP ROLE="Slide Show">
   <LINK ROLE="Slide 1" HREF="slide_1.html">
   <LINK ROLE="Slide 2" HREF="slide_2.html">
   <LINK ROLE="Slide 3" HREF="slide_3.html">
   Click here to view the WebRouser slide show </GROUP>

Message                  Description

DHOEserverUpdate         Tells a client to update data.
DHOEserverReady          Tells a client the server is ready.
DHOEserverExit           Tells a client the server is exiting.
DHOEserverConfigureWin   Tells a client to resize/reposition the DHOE window.
DHOEclientAreaShown      Tells the server the DHOE area is exposed.
DHOEclientAreaHidden     Tells the server the DHOE area is being hidden.
DHOEclientAreaDestroy    Tells the server the DHOE area is being destroyed.
DHOEbuttonDown           Sends mouse-pointer coordinates to the server on button down.
DHOEbuttonUp             Sends mouse-pointer coordinates to the server on button up.
DHOEbuttonMove           Sends mouse-pointer coordinates to the server on button move.
DHOEkeyDown              Sends the corresponding keysym to the server on key down.
DHOEkeyUp                Sends the corresponding keysym to the server on key up.