Chapter 9

Understanding Plug-Ins

CONTENTS

• The World Before Plug-Ins
• How Helper Applications Work
• Extending the Functionality of Netscape
• Building Your Plug-In
• In the SDK…

Netscape Navigator is a well-designed, highly functional product. Netscape's innovations have catapulted the company to its position as leader of the Web browser vendors. Navigator provides native support for a variety of graphics formats as well as the Hypertext Markup Language (HTML), the language of Web pages.

Netscape, however, recognizes that the needs of the Web community are changing faster and growing wider than Navigator can support. Starting with version 1 of the product, Netscape provided ways to extend Navigator with "helper applications," which support data formats beyond the built-in graphics and HTML.

Starting with Netscape Navigator 2, Navigator supports "plug-ins," another way to extend the range of data types that can be presented on or with a Web page.

The World Before Plug-Ins

To see why plug-ins are useful, go to the desktop of your computer and double-click a few documents. If you choose a document that your system associates with a particular application, that application is launched. But, if you double-click a document whose type is not associated with a known application, you see a dialog box like the one shown in Figure 9.1.

Figure 9.1 : A Windows 95 user is invited to "associate" a file extension with an application.

On the whole, Apple and Microsoft have developed workable schemes for mapping documents to applications. Even most UNIX vendors provide similar schemes with the X Windows System.

The users' world today, however, goes far beyond their local hard drive. They may have files on a file server on the local area network. They may access files on a coworker's machine on the other side of the room or, through a company intranet, the other side of the world. They also may use a variety of files from the Internet.

When a Netscape Navigator user attempts to open a document that Navigator does not recognize, the dialog box shown in Figure 9.2 appears. This dialog box allows the user to select an external viewer application through the Pick App button or save the file.

Figure 9.2 : A Navigator user attempts to open an unrecognized file type.

External viewers, also known as helper applications, allow the Web user to see a variety of data types that are not built into Netscape Navigator or other popular browsers. Figure 9.3, for example, shows a graphic stored in Computer Graphics Metafile (CGM) format-a format popular with the Computer-Aided Design (CAD) community. This image is viewed from Netscape using FIGleaf, a plug-in from Carberry Technology.

Figure 9.3 : CGM graphics can be viewed through helper applications or plug-ins.

The downside of helper applications is that they are, indeed, applications. To view a file with a helper application the user's machine must start an entirely new program, which means that:

• They have to wait while the new program loads.
• They may run out of memory and not be able to launch the new program.
• If the helper application launches, they see the document in its own window, out of context from the Web document.
• No interaction exists between the Web document and the external file-for example, if the external file is a movie, similar to that shown in Figure 9.4, no provision is available to allow the user to use buttons on the Web page to control the movie viewer.

Figure 9.4 : This Macintosh QuickTime movie viewer has its own set of controls-the user cannot run it from the Web page.

How Helper Applications Work

To understand helper applications, you must first understand MIME types. Multimedia Internet Message Extensions, or MIME, was developed to allow users to exchange files by e-mail. Although the Web doesn't use the full MIME standard, it is convenient to use media types (formerly known as MIME types) to tell a Web browser how the file is formatted.

MIME

MIME is described in detail in Request for Comments (RFC) 1590. RFC 1590 updates the registration process originally described in RFC 1521. Although MIME was originally intended for use in e-mail systems (and RFC 1521 was written with this application in mind), today's user encounters MIME in a variety of multimedia settings.

MIME is designed to have a limited number of top-level types, such as application, text, and video, which can be extended by subtypes. Table 9.1 shows some typical MIME-compliant media types.

When a Web browser requests a document from a server, the server sends several header lines before it sends the document. One header is Content-type. This header line contains the MIME type and subtype, separated by a slash. Therefore, most Web pages are preceded by the following line:

Content-type: text/html

How Web Servers Select a Media Type

Most Web servers have a file that associates file extensions with MIME types. On NCSA, Apache, and similar servers, the file is named mime.types. A typical line in mime.types says the following:

text/html html

This line tells the server that if the file has an extension of .html the server should send text/html in the Content-type header.

Suppose that you want to serve Microsoft Word documents, in their proprietary format, directly from your Web server. If your Word documents use the file extension .doc, and they are the only documents with that extension, you can add the following to mime.types:

application/msword   doc

Equivalently, you could put the following line into the configuration file srm.conf:

AddType   application/msword   doc

How Web Browsers Handle Media Types

Start Netscape Navigator and go to Options, General Preferences. From the General Preferences dialog box, choose the Helpers tab. The result should resemble the screen shown in Figure 9.5. (Figure 9.5 shows the screen in the Macintosh version of Navigator. The exact appearance of the screen may vary slightly from one platform and one version of Navigator to the next.)

Figure 9.5 : Navigator allows the user to associate applications with media types.

Note that if Navigator recognizes the media type, it uses the common name (such as CompuServe Image Format for image/gif). Some formats, such as GIF and JPEG, are handled internally by Navigator. Others are handled by helper applications or plug-ins, which are discussed throughout the rest of this book.

Select a media type that is handled by a helper application and click the Edit button. The Edit Type dialog box is shown in Figure 9.6. Notice that in this dialog box, the user can specify the MIME-compliant media type and subtype as well as a file extension. The information in Figure 9.6 says that if Navigator encounters a header from the server that identifies the content type as image/cgm or if it is asked to open a file that has a file extension of .cgm, Navigator should launch the helper application, PowerPoint PowerMac Stub.

Figure 9.6 : Navigator allows the user to specify an application with a MIME type and subtype and a file extension.

To add a new media type to the list that Navigator recognizes, go to the Helpers tab in the General Preferences dialog box, and click the New button. The resulting dialog box is identical to the one used by the Edit button. Fill in the fields and click OK.

Figure 9.7 : Microsoft Word 6.0.1 for Macintosh recognizes 18 different Macintosh file types.

What Helper Applications Can and Can't Do

Helper applications represented a good first-step at extending Navigator to non-native data types, but there are limitations. This section explores some of the reasons that helper applications, by themselves, may not meet the needs of many Web users.

Many Different Applications  Recall that common applications such as Microsoft Word can be configured as helper applications to read their own proprietary formats. Many such applications occupy tens of megabytes and cost hundreds of dollars. Although intranet users may have a standardized set of applications, Internet users are unlikely to buy the full application in order to read a document in a proprietary format.

A reader application is needed that will allow the user to see the data, without necessarily having the capability to change the data.

Separate Windows  Helper applications are, after all, applications. As shown in the example with Microsoft Word, they do not need to be written in a special way-Navigator downloads the file from the Web and then invokes the application. The application opens the file and displays it in its own window, with its own menu bar, just as though a user had launched the application and chosen File, Open.

When the application launches, it takes several seconds to load into memory. If the computer memory is already full (with Navigator and other applications), the application may not load at all. If it does load, the user is very much aware that he or she no longer is interacting with Navigator-the user now is in the helper application.

Many Webmasters wish they could embed files from a variety of formats in their documents and keep the user in the Navigator window and menu bar. Navigator needs a way to reference a file from inside an HTML document and have Navigator invoke a reader to display the file inline.

No Interaction with Navigator  Many data types require more interaction than just "reading." Audio and video data can be started, stopped, played at normal speed, played faster, or played slower. Navigator is being positioned as the "universal client"-to live up to that name, it should take control of embedded data.

Many Webmasters would appreciate the capability to hook buttons or other controls on an HTML page to the helper application so that a user can interact with the application and the data through controls on the page.

Waiting for the File  Hypertext Transfer Protocol (HTTP)-the protocol of the Web-is designed to allow browsers to request an entire file from the server. When the file contains HTML, it usually downloads in only a few seconds. A graphic image such as a GIF or JPEG may take half-a-minute or more but multimedia files, such as sound and video, can take many minutes-so long that most users are not pleased with having to wait. This "dead air" that accompanies large files is one reason that more multimedia is not displayed on the Web.

Some vendors, such as Progressive Networks, makers of RealAudio, developed alternative protocols that allow their clients to present the data as it downloads. A user listening to RealAudio begins to hear sound a few seconds after he or she connects, while the rest of the file continues to download.

Users would welcome a byte-oriented protocol (rather than a file-oriented protocol) because it would allow them to begin to display, play, or listen to the data as soon as it is available, rather than being forced to wait until the entire file has downloaded.

No Interaction with the Web Site  Much data on today's Web is static-the file is stored on the server until it is requested, and then it is downloaded to the browser. But some applications would benefit from more interaction. An application, for example, that displays video data as it is downloaded would benefit from a Fast Forward control that tells the server to skip part of the video.

Application programmers could use a mechanism that allows them to communicate (through Navigator) back to the server.

Extending the Functionality of Netscape

In Navigator 2.0, Netscape introduced inline plug-ins as an alternative to helper applications. Plug-ins are platform-specific pieces of code that display their contents inside the Navigator window, very similar to the way the HTML <IMG> tag displays an image inline rather than in a separate window. This technology affords the following features:

• Plug-ins are small code resources, not full applications. They are run in the Navigator process. Consequently, they cost less to develop, take up less disk space, and load more quickly than full applications.
• Because plug-ins share address space with the Netscape application, they can run in the Navigator window. The HTML coder can embed references to the data directly in the HTML file, and the plug-in will open inline in the Navigator window. The coder still can have a full window if he or she chooses. There also is a provision to run plug-ins in the background when no graphical interaction is required, such as for an audio application.
• The plug-in is activated as soon as the data begins to flow from the server. The programmer has the option of waiting for the data to be stored as a file, but the recommended programming technique is to present the data as it arrives.

In mid-1996, Netscape released Navigator 3.0. Navigator 3.0 supports additional plug-in capabilities. In particular, it includes a technology Netscape calls LiveConnect, which integrates plug-ins with client-side JavaScript and Java. Figure 9.8 illustrates LiveConnect.

Figure 9.8 : LiveConnect is Netscape's approach to integrating all of the client-based programming techniques.

JavaScript is a high-level object-oriented language, principally designed for use in the browser. (There also is a server-side version of the language that works with Netscape's second-generation servers and the LiveWire toolset.) JavaScript is an approachable language, and many programs have been written in JavaScript by people who do not consider themselves professional programmers.

Java is a powerful object-oriented language. Java programs can be compiled into applets and stored on the server. When the browser requests a page that references these applets, the applets are downloaded and run on the browser.

Although plug-ins are written in the native code of the client platform (OS/2 Warp, Windows, Macintosh, or a specific version of UNIX), Java is platform-independent. A Java applet can run on any platform that supports the Netscape Navigator browser.

With LiveConnect, a JavaScript programmer can include plug-ins and Java applets on the same page and can issue calls to both entities to control them or send them information. Plug-ins and applets can also call JavaScript functions to determine how they should proceed. This level of integration means that applets and plug-ins, which are usually written by skilled programmers, become a code resource for use by page designers, extending the reach of page designers who do not necessarily have to be able to write sophisticated programs.

See Part V, "LiveConnect."
See "Client-Side JavaScript," p. 139
See "Overview of Java," p. 185

Your Own MIME Media Type

Unlike Java applets, which are mini-applications, plug-ins are intended to be built around data. Before you can build a plug-in, you (the developer) must specify the MIME media type(s) that the plug-in handles. Many plug-ins will be able to work with an existing MIME media type, such as the Computer Graphics Metafile format shown earlier in this chapter (in the section titled "The World Before Plug-Ins") or those listed in Table 9.1. However, sooner or later you will need to give users access to data that has no MIME-compliant media type. This section explains two ways of dealing with this situation, depending on whether your data will be distributed privately or publicly.

Private MIME Types  If you develop a plug-in strictly for an intranet or for a limited Internet audience, you may decide to specify your own type of MIME media. Usually, you can use an existing type, which only requires that you select a subtype. By convention (and in accordance with RFC 1590), unregistered types and subtypes begin with x-. Therefore, you may see application/x-zip, audio/x-mpeg, and image/x-png.

Registering a MIME Type  The procedure for registering MIME media types is given in Part 2 and Appendix A of RFC 1590, which updates RFC 1521. RFC 1590 was issued in March 1994. Before you start the registration process, always check the list of RFCs to see if there is a newer RFC that updates RFC 1590.

To register a new media type, first select a top-level type from the current list (such as application, image, video, or audio). Then select a unique name for the subtype. Send a message to the mailing list [email protected]-readers of this list will comment on the appropriateness of your choice. A typical message format would be as follows:

To: [email protected]
Subject: Proposed new Media Type content-type/subtype
Media Type name:
Media Subtype name:
Required parameters:
Optional parameters:
Encoding considerations:
Security considerations:
Published specification:
Person and e-mail address to contact for further information:

If the Media Type name field does not contain an existing top-level Media Type, the IANA needs an explanation of why an existing top-level Media Type cannot be used.

The Published specification field should contain a reference to a publicly available specification. If the request is for a new top-level Media Type, the field should reference the RFC or RFC-to-be, specifying the new type.

The Security considerations field is the place to list any known security risks. The IANA does not require that your application be secure, only that all known risks be identified.

Allow two weeks for comments and feedback. If, based on the comments, you decide to change the name of your type, it is a good idea to send the amended proposal back to the mailing list.

After your proposal is reviewed by the ietf-types mailing list, send a message to [email protected] to start the registration process. Use the same format as the ietf-types mailing list but make the subject "Registration of new Media Type content-type/subtype."

The IANA will ensure that your proposal has been reviewed by members of the Internet Engineering Task Force through the ietf-types mailing list. Then they will register your new type, assign an Object Identifier (OID) under the IANA branch, and post the registration on their FTP server, at ftp://ftp.isi.edu/in-notes/media-types.

Your media type also will be published in RFC 1340, "Assigned Numbers." If you expect that the Internet public will want to put data into your new format or will write plug-ins or other applications to read your data, put the full specification into an informational RFC.

Migrating Applications to the Web

Many software publishers have developed applications that generate and read documents that can be sent over the Web. Plug-ins are an excellent way to extend the viability of an application. Get a media type assigned for each data format your application produces, and then write a plug-in that reads and presents your data to the user. You may even want to use JavaScript and LiveConnect to allow the Web user to interact with the data.

One example of this approach is Adobe's Portable Document Format (PDF). Adobe makes the plug-in (and before that, the helper application) available at no charge from its Web site. Adobe sells Acrobat, which writes these PDF files, through commercial channels. The result? The Internet community has a huge demand for PDF files and sales of Acrobat are brisk.

Building Programming Resources for HTML and
JavaScript Programmers

In the late 1970s, when the first desktop computers were being offered, thousands of people who did not consider themselves professional programmers learned BASIC, an interpreted language that was built into most desktop machines. Teachers, insurance agents, and bankers all wrote small BASIC applications that met specific needs in their industry. The same phenomenon occurred again in the early 1980s when spreadsheets appeared.

During the late 1980s and the early 1990s, the computer industry realized that the number of trained programmers would fall far short of the demand. Many companies are building on the BASIC and spreadsheet models-they are making it possible for professional programmers to build reusable components, which then are used by sophisticated users to build complete systems. A skilled user can use client-side and server-side JavaScript to stitch together data, plug-ins, and Java applets into a complete solution for use on an intranet or the Internet.

For plug-ins to be used as components, they must have the following three characteristics:

• A well-documented data type.
• A well-documented interface (both with the Netscape EMBED tag and with JavaScript).
• A high tolerance for errors-the plug-in should recover or exit with a message explaining the error, rather than crash.

Building Your Plug-In

Unlike Java applets, plug-ins are written in platform-specific code. Netscape Navigator is available for OS/2 Warp, Windows 3.x, Windows 95, Windows NT, 680x0-based Macintoshes, PowerPC-based Macintoshes, and a variety of UNIX platforms. If you want your data to be readable by any Navigator user, you need to develop versions of your plug-in for all of these platforms.

The good news is that the code for plug-ins is quite similar across platforms. In some cases, you can use the same code and compile for different targets. Microsoft's Visual C++, for example, can generate code for Intel processors (running all manner of Windows), the Macintosh (both 680x0 and PowerPC), and even the DEC Alpha chip (running Windows NT). MetroWorks CodeWarrior Gold for the Macintosh can generate code for both types of Mac processors as well as Windows 95 and Windows NT.

Differences between platforms usually have more to do with the graphical user interface (GUI) than with the interface between Navigator and the plug-in. Windows applications will call the Windows API (possibly through Borland's Object Windows Library, OWL, or Microsoft's Foundation Classes, also known as MFC). Macintosh applications use the Macintosh toolbox, which is built into every Mac. UNIX programmers can choose from a wide variety of "widgets"-pre-built objects that fit into an X Windows System environment.

Because a complete plug-in should be available on all platforms, this book contains information relevant to all four major operating systems. Where the operating system is irrelevant, most examples are drawn from the Windows 95 platform and are shown in Microsoft Visual C++.

Downloading the Navigator Plug-Ins SDK

Netscape distributes its plug-in Software Development Kit on its Web site, at http://home.netscape.com/eng/mozilla/3.0/handbook/plugins/index.html. You can also get this information from http://home.netscape.com/comprod/development_partners/plugin_api/index.html, shown in Figure 9.9.

Figure 9.9 : You can develop plug-ins on all major platforms.

Visit the Netscape site and download the version of the SDK appropriate for your development platform.

Unpacking the SDK

Each version of the SDK is compressed in a way that is appropriate for the platform (for example, the Windows version is ZIPped, the Macintosh version is a Stuff-it archive, and the UNIX version is compressed using tar). Copy the SDK to the directory of your choice and unpack it.

Configuring the SDK

You need a C++ compiler to build Navigator plug-ins. Netscape's SDKs are built from its engineers' computers and do reflect the software tools that Netscape uses internally. On Windows, Netscape uses Microsoft's Visual C++. On the Mac, it uses Metrowork's CodeWarrior. Most versions of UNIX come with a native C/C++ compiler. IBM recommends IBM's Visual Age C++ 3.0 for building plug-ins for OS/2 Warp.

Although you can build plug-ins with any C++ compiler, you have less work to do if you use the same compilers as Netscape. For example, some portions of the Windows example plug-in rely on Microsoft Foundation Classes. The Symantec compiler comes with MFC-the Borland compiler is bundled with OWL, which offers similar capabilities. The Borland compiler also can be used to recompile MFC, if you get this library from Microsoft. Visual C++, however, is available in versions starting at under $100-for learning to build plug-ins, a copy of Visual C++ shortens your learning time.

Figure 9.10 illustrates the process of turning a high-level language such as C or C++ into an executable file. The compiler produces object code, often signified with a file extension of .obj or, occasionally, .o. The linker puts together these object files with platform-specific code, like the code that makes up the Windows or Macintosh API. The finished product is an executable file. On either a DOS or a Windows computer, this executable has a file extension of .exe.

Figure 9.10 : Source files are complied, then linked with other object files to make an executable image.

For years, all linking was done by the developer when the product was built. Today, all major platforms allow programmers to build code resources that can be linked into applications when the application loads or even during runtime. Libraries designed to be linked on the user's computer are known as dynamic libraries; libraries designed to be linked on the developer's machine are static libraries.

When an application statically links a library, the object files from the library become a permanent part of the application, and the size of the application grows. Dynamic libraries are attractive when the libraries will probably be used by more than one application. Then, applications take up less disk space and memory because they share the library. Figures 9.11 and 9.12 illustrate this difference.

Figure 9.11 : Static libraries are built into the application when it is developed.

Figure 9.12 : Dynamic libraries are linked in as they are needed, either at runtime or as the application is loaded.

Each SDK comes with a copy of Netscape's documentation in HTML files. After the kit is unpacked, use Navigator to open the doc/index.html page and then to bookmark it. You use this page as the starting point to the online documentation.

Windows  Microsoft Windows allows programmers to write code either as applications or as dynamic link libraries (DLLs). The principal difference is that applications have a function named WINMAIN() that serves as their starting point and DLLs do not. This design makes it easier to build a DLL that can, with few changes, be readily compiled into an executable application-a technique demonstrated in Chapter 13, "Analysis of a Simple Plug-In." Rather than defining a WINMAIN() function, Windows DLL programmers must explicitly export function names from the DLL to the calling program.

Netscape plug-ins keep information about which MIME types they handle in their VERSION resource. When Navigator starts, it looks in the directory that holds the Navigator executable for a folder labeled Programs. Inside this directory, it looks for a folder labeled Plug-ins. It examines the VERSION resources of each file in the Plug-ins folder and reads out the MIME type.

Later, when it encounters a Content-type header with a type it does not recognize, it scans the list of MIME types that are registered by the plug-ins. If it finds a match, it loads that plug-in DLL into memory and calls the exported functions.

OS/2 Warp  Early in the life of the Web, IBM announced its own browser (Web Explorer) for OS/2. In mid-1996, IBM announced that it was adopting Netscape 2.02 as the standard browser for OS/2 (though they have adapted it to include some of the nicer features of Web Explorer, such as speech input). IBM and Netscape also took a different approach to integrating Java. Since OS/2 version 4 already has Java integrated into the operating system, Navigator calls OS/2's Java rather than its own Java interpreter. These differences should be transparent to the user and the developer.

IBM will probably not offer Netscape 3.0 for OS/2. Instead, they are working with Netscape to bring Netscape 4.0 (Galileo) to OS/2 Warp. Look for Netscape 4.0 for OS/2 early in 1997.

Unlike the SDKs for the other platforms, the OS/2 Warp Plug-Ins SDK is stored on the IBM site, rather than on the Netscape site. You get it from http://www.internet.ibm.com/browsers/netscape/warp/.

If you develop OS/2 Warp plug-ins before Galileo is released for OS/2, remember that you only have Netscape 2.02 features. Most importantly, this fact means you have no LiveConnect capabilities, so you cannot integrate Java and JavaScript with your plug-in.

Be sure to download the plug-in documentation that comes from the IBM site. This version is almost identical to the version on the Netscape site but includes the instructions specific to OS/2 Warp development.

Visual Age C++ relies heavily on makefiles. To specify the MIME media type and file extensions in your plug-in, use the compiler's editor to modify the makefile. The easiest way to do this is to make a working directory in the SDK directory and copy the contents of the npshell directory into your new working directory. (You may want to name the working directory myplugin.) Now open the makefile copied in from npshell, changing the RCDATA lines to reflect values appropriate for your plug-in. For example, if you are writing a plug-in that plays AVI movies, the makefile should include:

#include "npapi.h"
       RCDATA NP_INFO_ProductVersion { 1,0,0,1}
       RCDATA NP_INFO_MIMEType       {"video/x-msvideo\0"}
       RCDATA NP_INFO_FileExtents    {"avi\0"}

RCDATA NP_INFO_FileOpenName   {"OS/2 Video Plugin\0"}

To include multiple MIME types in the plug-in, use a vertical bar to delimit each value in the MIME type. For example, VALUE "MIMEType", "video/x-msvideo | video/quicktime\0" specifies that the plug-in will handle both AVU (x-msvideo) and Quicktime video types.

On OS/2, Netscape looks for plug-ins by starting at the directory that holds netscape.exe and by looking "down" for a plug-ins subdirectory. You don't have to start the plug-in name with np unless you want to for consistency with the Windows versions of the plug-in.

Macintosh  Applications in the Macintosh operating system are based on resources. Each Macintosh application has two CODE resources. (It may have more, but it must have these two.) CODE resource 1 is known as the "main segment." This segment is loaded when the application starts and is not unloaded until the application exits. (CODE resource 0 is used for housekeeping and is not a concern here.)

Not all code is kept in CODE resources. The Mac has a lot of little code resources tucked into resources like CDEFs (Control Definition Functions, for drawing controls) and MDEFs (Menu Definition Functions, for drawing menus). It switches from one printer to another by switching PDEFs (Printer Drivers) at runtime.

When Navigator is launched on the Macintosh, it looks for the folder that contains the Navigator executable; then it looks for a subfolder named Plug-ins. Finally, it searches each file in the Plug-ins folder for a resource named NSPL with an ID of 128. If it finds this combination, it knows that file contains a plug-in. Navigator then looks for a string resource (STR#) with ID 128. Macintosh STR# resources contain lists of strings. STR# 128 contains the MIME types that this plug-in recognizes.

Later, when Navigator encounters a stream from a server, it compares Content-type headers with the MIME types it read from the plug-ins. If it finds a match, it loads the resources of this plug-in into memory and calls functions in the plug-in.

UNIX  Most versions of UNIX allow a program to build what are named .so libraries, shared object files that function like Windows DLLs. The instructions for building a shared object library vary slightly between UNIX versions. Significantly, AIX (IBM's version of UNIX) supports shared object libraries by using the same export mechanism as Windows. This process is sufficiently different that Netscape does not yet support plug-ins on its AIX version of Navigator.

UNIX uses a mechanism similar to the mechanism described for Windows and Macintosh. It looks through the shared objects in the Plug-ins directory for libraries that advertise Netscape plug-in functions. When UNIX finds these libraries, it looks up the MIME types they handle and then links and loads the correct plug-in at runtime.

In the SDK…

From the beginning, Netscape Navigator has supported helper applications that allow users to access data types other than the ones built into Navigator. The mechanism for describing these data types is the MIME-compliant media type.

Starting with Navigator 2.0, Netscape supports inline plug-ins, which allow programmers to write native code to read data and to present it inside the Netscape window.

With Navigator 3.0, Netscape introduced LiveConnect, which integrates plug-ins, JavaScript, and Java. Now all of the programming techniques for the client can be brought together into an integrated solution.

Starting with Navigator 4.0, Netscape is supporting automated downloading and installation of plug-ins, making the use of plug-ins even more transparent to the end user.

The programmer who wants to field a complete plug-in solution will need to build his or her plug-in on all major platforms. This book presents solutions for the OS/2 Warp, Macintosh, and UNIX machines, while emphasizing Windows 95 and the Microsoft Visual C++ compiler as an appropriate and readily available learning environment.