3. Accessing WWW resources from PLINTH

To connect PLINTH to the WWW then, we need to add three things: (i) a communication module for formulating and sending http, ftp and gopher requests and reading the response; (ii) routines for formatting and rendering the textual and graphical contents of the HTML pages and other multimedia resources that are returned; and (iii) a means of accepting user input to determine which resource to load next (e.g. via mouse-clicks as in Mosaic).

3.1 Communications

Although it would be possible to write a complete communications module for PLINTH from scratch, it would be a very complicated and time-consuming task requiring detailed knowledge of the protocols used and experience in writing networking software to do a proper job. Also, the software would have to keep up with any future revisions of the protocols. Fortunately, there is no need to expend such effort, as there already exists in the public domain an excellent, well-tested WWW communications package, libWWW [11] produced by the CERN team and used in NCSA Mosaic. The package is written in C, so it should be quite straightforward to write a Pop11 interface to it for use in PLINTH, and upgrading this interface to work with new releases of libWWW should be a minor task. The only potential drawback with using any public domain software is the possible future commercial exploitation of PLINTH, although at the moment the use of libWWW does seem to be completely unrestricted.

3.2 Displaying WWW resources and interacting with the user

The display of non-HTML resources presents no problems for PLINTH. Plain text, X bitmaps and GIF images can be viewed in TOME, and like other WWW browsers such as Mosaic, PLINTH can rely on standalone, mostly public domain programs (which the client site is responsible for installing) for displaying other resource types, e.g. xv for images, GhostView for PostScript, AudioFile for sound, and mpeg_play for movies. The user may specify a mapping from MIME types to programs to override the default viewers if needed. The auxiliary nature of these resources makes this approach quite acceptable.

HTML itself could be displayed in TOME using the public domain HTMLWidget [12] an X Toolkit widget used by NCSA Mosaic. This widget takes an HTML string as the value of its XtNtext resource and displays it, formatted, in a window (although routines for rendering inlined images are not built in). However, unlike libWWW, using the HTMLWidget could really only be classed as a 'quick and dirty' method: it is useful for getting WWW access up and running as soon as possible in order to demonstrate its usefulness, but it has serious drawbacks. The user would be faced with two kinds of TOME window with rather different looks and behaviour: one editable, the other not; one where buttons (i.e. source anchors) are true nodes, one where they are not; one where internal reference fragments (i.e. destination anchors) are highlighted regions, one where they are a single point in the text; and two distinct text selection and highlighting schemes. In short, it would be a confusing mess. For something that could become a very important central feature of PLINTH, a less superficial approach, more deeply integrated with the main system, is highly desirable.

Two solutions are available. Firstly, and more easily, we can add conversion routines to PLINTH for pre-formatting the HTML into a TOME buffer (keeping the distinct appearance of bold and italic text but not the variety of font sizes) which can then be viewed and edited in a regular TOME window. HTML link anchors can be converted into proper button nodes which have a URL slot rather than a normal reference link to another node. The TOME representation can be converted back to HTML if the file is saved locally. Inlined images could be displayed simply as cross-reference buttons to separate windows (i.e. not inlined at all), or image display facilities could be added to TOME (a major task, since the Poplog XpwScrollText widget that TOME uses for its basic display and input of text does not support graphics, and would have to be re-implemented from scratch).

The second, and much better, solution would be to use a version of HTML as TOME's native text format, and avoid the conversion altogether. The next section of the paper looks at the possiblities for achieving this.

Using HTML as TOME's native text format...