Once the HTTP (and other protocol)-communication code is separated into an
independent object, it can be integrated into _any_ software that supports the
respective object model. Thus, a word processor could retrieve documents via
HTTP, Gopher, or FTP just as easily as retrieving them from the local hard disk
or LAN, it would also be able to use the HTML parser object to convert the file.
A database application could opt to use HTTP, WAIS, or Z39.50v3 as well as
SQL to do remote lookups. In my field, we could have Geographic Information
Systems software where map themes on the local disk could be combined with
themes stored anywhere else without having to first download all the data.
In this model, today's NetScape or Mosaic would be a "federation" (in the Swiss
sense) of the following modules:
HTTP transport
Gopher transport
NNTP transport
WAIS transport
FTP transport
Local file I/O
Printer control
HTML parser
Gopher menu parser
GIF/JPEG/XPM/etc parsers
Document Manager
In addition, new modules could be added/upgraded as necessary:
VRML parser
SVF/CGM parser
MPEG player
Sound players
PostScript parser
Acrobat/Envoy/Folio parsers
HTML 3 parser
HTTP 2 transport
Gopher+ transport
Z39.50 transport
Unlike what some have worried about, these modules need not be split into 9
windows cluttering up the screen. The componentware browser would look the
same as it does today, using the Document Manager to integrate everything
into a single multimedia document (unless the user/provider wants separate
windows).
Now that I've given all that ideal, I must ask that we not reinvent the wheel
by developing a new object sharing model (at least nothing more complex than
CCI). We are not the only ones moving toward componentware, and models abound.
I firmly believe that we should rely on emerging industry standards such as
CORBA and OpenDoc (see the May 1994 Byte for a good introduction to this
concept and the coming standards), which should have all the power we need.
Brandon Plewe
plewe@acsu.buffalo.edu