[Home] [ToC] [Up] [Prev] [Next]
This section provides an overview of what is required to integrate the iHTML system into an existing World Wide Web browser. Because of the scope of this type of effort, this section does not attempt to be a detailed step-by-step guide; rather, it presents a high-level view of some of the things that must be done and the issues involved.
There are two main steps to such an endeavor: implementing the browser glue, and programming the interaction with the iHTML system. The first involves writing all of the various browser interface functions and types, as described in the browser services, that the iHTML system requires. This provides the system with the hooks it needs to call back and manipulate the browser.
The second step, interaction with the iHTML system, involves inserting calls from inside the browser code into the iHTML library. This is required because it is up to the browser to drive the overall system -- it submits HTML documents to the iHTML library as needed to display them, informs it of embedded objects in the document, and must explicitly send all interface events into the iHTML system to be processed.
The browser glue that provides access to a browser's internal implementation can actually be divided into two categories: operating system glue, and the browser glue itself.
The operating system glue is the set of services that a browser does not normally need to concern itself with directly. This typically includes the functions for retrieving and examining dynamically loaded code modules, managing search paths and directories, graphical user interface objects, and some parts of the event system.
The OS glue is typically implemented separately from the browser itself, as a set of OS-specific modules. This allows the browser developer to avoid re-implementing the routines, as long as the glue modules are available. For example, the X Mosaic implementation includes separate glue modules for both Unix and the X Window System. The Unix glue implements dynamic loading of code modules, path and directory management, and opening files. The X glue implements the complete package of user interface services, translating various X types (pixmaps, widgets, colors, etc.) into their associated iHTML representation. It also provides standard code for manipulating iHTML events that are associated with standard X events.
The true browser glue implements the remaining services. Some of the most important of these are the browser markup services, which allow the system to manipulate the browser's internal representation of its HTML parse trees. The system relies on these to parse the document scripts and applets that occur in a document.
Note that the browser must provide a true tree structure to the rest of the system. This can be a problem, because many existing browsers (include X Mosaic) only manage the HTML documents they parse as a simple flat list. In addition, the browser needs to be able to associate an arbitrary language module and object with each node in the tree.
The NCSA X Mosaic glue implements this functionality by adding four new fields to the browser's node definition:
struct ih_language_rec* lang; /* Language of owner */ IHMarkup owner; /* If not NULL, the script object that made this */ struct mark_up *parent; /* parent of this node, for tree traversing */ struct mark_up *prev; /* previous node in linked list */
The first two are obviously used to store the language and object associated with a node. The others turn Mosaic's singly-linked list structure into a tree: each node now stores its parent node in the tree, as well as the previous sequential node. Because Mosaic places both the open and close tag onto the list, enough information is supplied for the browser glue to manipulate the list as a true tree. One of the additional jobs of the browser glue is to go through a list of HTML nodes constructed by the browser, and correctly fill in the new fields.
The glue to Mosaic's URL retrieval mechanisms is fairly simple, as the browser does not support asynchronous network access. The glue simply calls upon the browser to retrieve the URL, then copies the returned data into the iHTML IHBufferP that it will be accessed through the URL request.
There are two small wrinkles in the implementation. The first is
the need to ensure the security of the requests, since they will
be used by insecure scripts to retrieved information over the
network. By
simply blocking any URL schemes that are considered insecure (such
as file:), URL access is made secure.
The second issue is that of the iHTML system's tcp:
scheme. This is not directly implemented by the system, but is a
part of the browser component. Since the Mosaic browser does
not directly support it, it has to be implemented in the browser
glue. Also, the implementation protects the
security of the system by only allowing network connections to the
machine from which a document was retrieved.
Along with the major services described above, the browser glue must implement the rest of the interface defined by the iHTML system. This includes the manipulation of a browser's documents, displaying messages, retrieving information about the browser, etc. These routines generally require little effort, simply mapping the calls into their equivalent browser functionality.
On the other end, the browser developer must make certain calls into the iHTML system to drive it. There are three main places this must be done: parsing new HTML documents, creating form controls in a document, and reacting to user interaction with the document.
When a browser is first getting ready to display a new document, it must send it into the iHTML system to be processed. This is done by calling the iHTML library's IH_ParseInterface() function, handing it the document's HTML parse tree. The iHTML system examines it for any document scripts or embedded objects, and starts a new interface context to it if there are. In addition, if there is a document script defined, the system will begin retrieving it and start its execution once it is available.
Next, the browser needs to call into the iHTML system as part of
its process of constructing the document display. This should be
done in the same way that it creates form elements, except it
hands
off any <OBJECT> tags it finds to
iHTML with a handle on a user interface widget that defines the new
object's
display context. The system will take care of parsing these tags,
retrieving the necessary data over the network, and starting the
objects' execution when they are ready.
Finally, document-related events need to be sent to the system so that they can be processed by a document script. This is accomplished by inserting code into any place where they will occur -- after printing or scrolling a document, highlighting a hyperlink, etc. This code creates a document class IHEvent with the correct code and data, and hands it off to iHTML with its IH_HandleEvent() function.
(One interaction not directly described here, events that occur in a widget, is typically handled by the operating system glue that implements the user interface services.)
[Home] [ToC] [Up] [Prev] [Next]
| Dianne Kyra Hackborn <hackbod@angryredplanet.com> | Last modified: Wed Oct 23 00:10:52 PDT 1996 |