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
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.