Netscape Plug-Ins

Many sources are available for Netscape plug-ins. Netscape maintains a web site of plug-ins organized by functionality or platform (see Resources 1 and 2). Netscape equips their browsers with a special plug-in called the “Default Plugin”, which is invoked when an unregistered MIME type is encountered. With user approval, the default plug-in will search the Netscape web site for appropriate plug-ins.

The Netscape web site is not the only source of plug-ins, although it may be the most convenient. Traditional sources such as Usenet newsgroups, WWW searches and even word of mouth can turn up useful plug-ins.

Be aware, however, that the same precautions should be used when downloading plug-ins as when downloading any other software. Although plug-ins are not full-fledged application programs, they can inflict just as much damage, intentionally or not. Unlike helper applications, plug-ins can cause the browser to leak memory, become unresponsive or even dump core. If the source code is available, you could inspect the code before compiling the plug-in yourself. Otherwise, you will have to trust the source of the plug-ins. Just because a plug-in is registered with Netscape's web page does not mean that Netscape provides any sort of warranty about the behavior of the plug-in.

Plug-ins are dynamic code modules, native to the platform on which the Netscape client runs. For example, Windows plug-ins are DLLs and UNIX plug-ins are shared object libraries. When Netscape Navigator starts up, it checks for plug-in modules in certain directory trees. Each plug-in candidate in the directory tree is loaded, its capabilities determined using the plug-in API (application program interface), then unloaded. Internal tables assign MIME types to particular plug-ins. Later, if the browser encounters a MIME type that requires plug-in support, the plug-in is reloaded and remains loaded until the page is closed. The list of registered plug-ins can be viewed using the “Help/About Plug-ins” menu. Removing a plug-in is as simple as deleting the shared library.

The README file which comes with Netscape Communicator for UNIX explains the algorithm for generating the plug-in list:

if($NPX_PLUGIN_PATH environment variable is set)<\n>
   Look at $NPX_PLUGIN_PATH, where
   $NPX_PLUGIN_PATH is a colon-delimited
   list of directories.
   else
   Look at all the following directories in
   order, overriding previous entries in case of
   duplicates:
      /usr/local/lib/netscape/plugins
      $MOZILLA_HOME/plugins
      $HOME/.netscape/plugins

The algorithm for Netscape 3.0 is even simpler. Only the directories /usr/local/lib/netscape/plugins and $HOME/.netscape/plugins are checked.

Only one plug-in or helper application can be assigned to each MIME type. These assignments are stored in the files $HOME/.mime.types and $HOME/.mailcap where they can be used by other applications. A dialog window allows users to resolve conflicts. For Netscape 3.0, the dialog is under the “Helpers” tab of the “Options/General Preferences” pull-down menu. For Netscape 4.0, the dialog is available via the “Edit/Preferences/Navigator/Applications” menu option. This menu also allows the user to associate file extensions with MIME types. Normally, the plug-in associates file extensions with MIME types when the plug-in is assigned to the MIME type.

You might have an idea for a great new Internet file format, but are wondering how to get Netscape to recognize it. You could be a web surfer whose favorite web site uses a file format unrecognized by Netscape or any of the available plug-ins. Or, you may just want to understand more about how your web browser works. In any case, the next few sections will briefly describe the process of designing and implementing your own plug-in.

First, a reminder about helper applications. If the file is not embedded within an HTML file, a helper application could also be used to display it. Helper applications are developed using traditional means, do not need to adhere to any special API, and do not require special debugging techniques. Even if your ultimate goal is a plug-in, it might be more efficient to first implement a helper application, then convert the helper application to a plug-in.

Once you have decided to build a plug-in, you will want to download Netscape's plug-in SDK (software development kit) (see Resources 3). The plug-in SDK includes documentation, example code and even a template plug-in, written in C, complete with Makefile. The SDK documentation includes a complete reference manual for the plug-in API, and some general guidelines for plug-in design. Rather than duplicate that information here, I will explore how to use the API most effectively.

The Netscape SDK is designed to facilitate cross-platform development. The SDK allows developers to use a single source tree for UNIX, Windows and Mac OS plug-ins. However, there are significant hurdles for the cross-platform plug-in developer. Different GUI standards, OS standards and device interfaces must be considered. Even the plug-in file format varies by platform. For example,Windows plug-ins must have names beginning with “np” and provide descriptive information via a version resource, rather than the API. I will skirt around the thorny issue of cross-platform development by focusing on UNIX-only plug-in development.