Viewing the Web -- the Web Components

The hush class library offers two ways to connect applications with the Web. Pages on the Web can be used as part of an application by employing the web component, for example for online help. On the other hand, these pages may contain embedded applets, defined by the application. Since most hush applications have a script interface as well, the application itself may be (recursively) embedded within such HTML documents  [DoornEl95].

Requirements of the Web Components

The design of the Web-related components of the hush library has been influenced by requirements such as extensibility with new data formats, data transfer protocols and support for active documents.

Data formats

The world of hyper- and multimedia abounds with data formats. For each type of media, such as text, sound and video, a few data formats play a prominent role. A Web browser should provide the means to show these data formats. However, viewer applications, separate from the browser, have some major drawbacks. For example, users have to use different interfaces and following links specified in a separate document is more difficult because of the loose coupling between the viewer application and the main browser.

A more elegant solution is to provide mechanisms to include the viewers into the browser itself, since it allows for a more uniform interface and for inlining the display of information, so that the user does not have to switch to another toplevel window. For example, it is possible to insert video fragments into an HTML-page or even to insert an HTML-page into another HTML-page.

The ability to support multiple data formats has been a major influence on the design of our Web components. At the moment our browser supports HTML, SGML, VRML, video (including MPEG, Quicktime, AVI) and a variety of image types. Developing new viewers and including them as integrated components into the framework is possible without much effort.

Data transfer protocols

The dominant communication protocol of the Web is currently HTTP, but new or enhanced communication and network transfer protocols will undoubtedly be needed. Examples include real-time protocols to incorporate continuous multimedia streams or protocols supporting safe data transfer. The DejaVu framework provides a testbed to experiment with these new protocols by plugging them into a Web environment.

Active documents -- client-side computing

A simple but powerful approach to active documents is to add the ability to run applets (mini-applications). At the moment our browser can execute Tcl-scripts (applets) that can be inserted into HTML or SGML documents, and the design is sufficiently open to add support for Java or Python applets as well.

Architecture of the Web Components

To satisfy our requirements, we needed a flexible and open design of the Web components. To achieve such flexibility and extensibility, we made use of the idioms mentioned in section dejavu. Recall that the virtual self-reference idiom is used to realize nested components and the dynamic role-switching idiom allows for multiple modes, for example to display a variety of document formats.

slide: Overview
Figure fig:overview shows an overview of the basic Web-related components of the hush library. The browser provides the toplevel user interface for all Web components, including a viewer, a scrollbar, navigation buttons (back, forward, home, reload) and an entry box to enter URLs. The client, web and MIMEviewer components form the conceptual base of our approach of connecting to the Web:
slide: Components
 Each component can be extended in a simple way.

The client component

The client component builds the bridge between the local web widget and the World Wide Web by providing an abstract and uniform interface to network (file) access and transport protocols. Figure fig:client shows the design of the client component.

slide: The client component
 To be able to add specific clients for new protocols, the dynamic role-switching idiom is used to implement the client class. The client implicitly changes its role, depending on the protocol required. The web widget only knows about the (abstract) client class while the actual functionality is implemented in several concrete client classes, one per protocol.

When the client gets the instruction to retrieve a URL, it inspects the URL and chooses the right protocol. In other words, it changes its role to the appropriate protocol implementation. The addition of new protocols can be done without changing the web widget.

The viewer component

In the realization of the MIMEviewer components we have employed the dynamic role-switching idiom in the same way as in the implementation of the client component. The MIMEviewer class offers a uniform interface to the different viewers (see figure fig:viewer).

slide: Viewers
The user creates a MIMEviewer object and tells which role it should play (e.g. SGMLviewer or VRMLviewer). This role can be changed during the lifetime of a single MIMEviewer object by calling a method to change its role. A browser typically uses only one MIMEviewer that changes its role according to the type of data that should be displayed.

Since the MIMEviewer provides no network functionality at all, it generates an event whenever it needs to retrieve data pointed to by a URL. Such events are generated as a response to user interaction (e.g. clicking an anchor) or to fetch inline data during the parsing process. These events (realized by the hidden urlevent class) are typically handled by a web component.

The web component

A central role in our approach is played by the web widget. It combines the functionality of the MIMEviewer and the client components. It is able to follow links by retrieving data via several protocols, a task delegated to its client component. Additionally, the web component adds a history and caching mechanism to the MIMEviewer. The web component's behavior is similar to the standard widgets of the framework, and can be conveniently used as a part of an application's GUI. Because the web widget has both a C++ class interface and a script interface, it is easy to create, or extend, applications with Web functionality. Note that the SGML viewer already allows for a rich variety of data formats, possibly extending HTML.