Chapter 25

Developing Content for Plug-Ins

by Mike Morgan

• Serving Multimedia Content on the Web
  • Understanding Netscape Navigator Plug-Ins
  • Configuring the Server and the Browser
  • Special Purpose Servers
  • Hardware Features
• Integration with HTML
  • HTML 3.2 and the <OBJECT> Tag
  • Three Ways of Invoking a Navigator Plug-In
  • Microsoft and ActiveX
  • Other Ways to Add Multimedia Content

High-end browsers such as Netscape Navigator and Microsoft Internet Explorer handle many different media types, but no browser can handle everything. Both Netscape and Microsoft have left "hooks" in their products to allow programmers to write code that extends the media types supported by the browser.

In Netscape Navigator, these browser extensions are called plug-ins. You can use plug-ins to display media types, such as audio and video, which were not included in Navigator's native media types. In fact, Netscape uses plug-ins to add functionality to its Navigator.

Microsoft's answer to plug-ins is a technology called ActiveX. ActiveX is actually several different technologies, all being marketed under the same name. The Microsoft technology used to display multimedia content is called ActiveX documents.

Serving Multimedia Content on the Web

Multimedia can be both the bane and the boon of a Web site. A text-only Web site, or a site with only simple graphics, can be boring and uninformative. But multimedia content increases the download time tremendously. A text-only Web page may download in three seconds or so, even over a slow dial-up connection. Adding a few graphics can stretch that download time to thirty seconds or more. Adding five seconds of video can add thirty minutes or more to the download time.

Because an effective site often needs multimedia content, and because such content can ruin a site's effectiveness, it follows that multimedia design decisions are among the most important decisions a Webmaster will make. This chapter addresses the topic of how to design multimedia content that is intended for general consumption by plug-ins. The next five chapters describe specific multimedia content: video, audio, streamed media, Shockwave animation, and business documents.

Understanding Netscape Navigator Plug-Ins

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

But Netscape recognizes that the needs of the Web community change faster and grow wider than it can support in Navigator. Starting with Version 1 of the product, Netscape provides ways to extend Navigator with "helper applications," which support data formats beyond the built-in graphics and HTML.

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

To see why plug-ins are useful, go to the "desktop" of a Macintosh or Windows 95 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 and creator are unknown, you'll get a dialog box like the one shown in Figure 25.1.

Figure 25.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 something of the same sort with the X-Windows system.

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

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

Figure 25.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. 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 a whole new program. This fact means:

• 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.
• There's no interaction between the Web document and the external file-for example, if the external file is a movie, like the one shown in Figure 25.3, there's no provision to allow the user to use buttons on the Web page to control the movie viewer.

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

Configuring the Server and the Browser

To understand helper applications and plug-ins, you must first understand MIME media types, formerly known as MIME types. Multimedia Internet Message Extensions, or MIME, were developed to allow users to exchange files by e-mail. While the Web does not use the full MIME standard, it is convenient to use media types to tell a Web browser how the file is formatted.

Understanding MIME Media Types  MIME is described in detail in Request for Comments (RFC) 1590. RFC 1590 updates the registration process originally described in RFC 1521. While MIME was originally intended for use in e-mail systems, and RFC 1521 was written with that 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 25.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 itself. One of the headers is Content-type. That header line contains the MIME type and subtype, separated by a slash. Thus, most Web pages are preceded by the line:

Content-type: text/html

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

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 you wanted to serve Microsoft Word documents, in their proprietary format, directly from your Web server. If your MS-Word documents use the file extension .Doc, and they are the only documents with that extension, you could add

application/msword   doc

to mime.types. Equivalently, you could put the line

AddType   application/msword   doc

into the configuration file Srm.conf.

Configuring Netscape Fast-Track and Enterprise Servers  Like the NCSA and Apache servers, Netscape servers use a mime.types file. Assuming the server is installed on a Windows NT server on the C: drive, in the directory named \Netscape\Server, and the server is named ns, the file is located in the directory C:\Netscape\Server\admserv\httpd-ns. A typical line might read

type=msword/cgi exts=doc

Such a line says that the server should interpret files with the extension .Doc as having content in the proprietary format of Microsoft Word.

You can change mime.types with any text editor. Be sure to restart the server after changing mime.types so the server reads the new version of this configuration file.

Configuring Navigator for Plug-Ins  When the Microsoft Windows version of Navigator starts, it looks in the directory that holds the Navigator executable for a directory called Programs. Inside that directory, it looks for a directory named Plugins. It examines the files in the plug-ins folder and reads out the MIME type. You can see which plug-ins Navigator found by choosing Help, About Plug-ins.

Later, when Navigator encounters a Content-type header with a type it does not recognize, it looks through the list of MIME types registered by the plug-ins. If it finds a match, it loads that plug-in Dynamic Link Library (DLL) into memory and passes the contents to the plug-in.

When Navigator is launched on Macintosh, it looks for the folder that contains the Navigator executable-then it looks for a folder inside there called Plug-ins (with a hyphen). Finally, it searches each file in the Plug-ins folder for an internal identifier that identifies the file as a plug-in. (On the Macintosh, plug-ins need not have a name which starts with np.)

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 that plug-in into memory and passes the stream to the plug-in.

If none of the plug-ins on the list match, Navigator looks at the list of helper applications. If none of those match, Navigator starts the plug-in assisted installation process. Figure 25.2, shown earlier, shows the installation dialog box.

Macintosh and UNIX users can specify which plug-in handles which MIME type (although few users may be aware of this). On those platforms, the user goes to Options, General Preferences and chooses the Helpers tab. The user can then specify which plug-in handles each MIME type, just like they would specify a helper application. Figure 25.5 shows the Helpers screen.

On Windows machines, the Helpers tab under Options, General Preferences does not include a plug-in option. The last plug-in to load gets to handle the MIME type. If you want to be sure a particular plug-in gets to handle the data, use JavaScript to discover the conflict and warn the user. (A JavaScript program for this task is shown later in this chapter.)

Special Purpose Servers

The Hypertext Transport Protocol, HTTP (the protocol of the Web), was designed for text and has been extended to graphics formats. HTTP was not originally designed for multimedia, in which a user may wish to skip from one part of the content to another without downloading the entire file. This section describes HTTP and shows why it is not the perfect choice for certain kinds of multimedia.

Next, this section describes the RealAudio servers from Progressive Networks. Progressive Networks allows a user to integrate inline audio into a Web page using their special servers.

Finally, this section concludes with a description of a new HTTP capability-byte-range extensions-which will enable the next generation of HTTP servers to support multimedia in a way that is similar to Progressive Networks' RealAudio servers.

Why Not Use HTTP?  High-quality sound, such as you might hear from a CD, needs much more bandwidth than, say, the human voice. When modem speeds topped out at 2,400 bps, the only way to serve sound was to send the entire file to the user and let them play it from their hard drive. While that method is still used for high-quality sounds, several companies have introduced inline audio for the Web. Inline audio can be linked to a Web page and played in the context of that page-it does not have to be downloaded for later playback. In fact, inline audio may even be used to serve the audio from real-time events such as a speech or a concert (though the quality is limited to that of a good FM radio station, at best).

Inline Audio in an HTTP Environment  RealAudio, a set of software from Progressive Networks, offers voice-grade inline audio. This company's latest product, RealAudio 2.0, does a good job of delivering music as well as speech. To perform these feats, Progressive Networks has developed a great deal of behind-the-scenes technology.

Recall from Chapter 11, "HTML Forms," that HTTP, the protocol of the Web, is meant to accommodate requests for files. When a client sends a GET, the server locates the requested entity, sends it back, and closes the connection.

This protocol is not well-suited for the way people listen to audio. They fast-forward, they rewind, they look for a four minute snippet out of a thirty minute file. HTTP is based on TCP, one of the two major ways packets can be sent over transmission control protocol/Internet protocol (TCP/IP) networks.

TCP emphasizes reliable delivery. As described in Chapter 11, TCP relies on a three-way handshake and packet numbers to make sure that the receiver gets every packet. If a packet is not acknowledged, the sender sends it again. If the connection quality is poor, the sender keeps trying to resend packets to make sure the receiver doesn't miss any data.

For inline audio, this guaranteed delivery is neither necessary nor useful. A two to three percent retransmission rate can bring a 14.4Kbps modem connection to a standstill. Figure 25.4 shows a typical client statistics screen with about a two percent error rate.

Figure 25.4 : Retransmission rates, as measured by the client, typically range from two to three percent.

One TCP/IP protocol that does not guarantee delivery is user datagram protocol (UDP). Using UDP, the sender sends out packets as fast as it can without waiting for acknowledgments. UDP is often used in TCP/IP applications for status reporting. If one packet gets dropped, it doesn't matter since a new status will be along momentarily.

With TCP, each retransmitted packet is delayed by a few milliseconds compared to where it should have appeared in the data stream. With audio, these delays begin to become noticeable when just two or three packets out of one hundred are retransmitted.

Another need specific to an inline audio server is a large number of connections. A typical Web server may have anywhere from 6 to 100 copies of the HTTP daemon running. A site serving a live audio event may have thousands or even hundreds of thousands of simultaneous connections.

Progressive Networks decided not to try to force this kind of behavior onto Web servers. Instead, it built its own server, which is available commercially, and its own client. The client is downloadable from Progressive Networks' Web site at http://www.realaudio.com/.

The server can use either TCP or UDP, although the best results are achieved using UDP. The RealAudio server gives good performance under modest retransmission levels (two to five percent) and degrades smoothly as retransmission levels approach ten percent.

To deal with packet loss, the RealAudio client does not request retransmission of any lost packets. Instead it makes an approximation of the lost packet based on the packets around it. For modest loss rates, the effect is not noticeable by most listeners.

Adding RealAudio to Your Site  Progressive Networks offers its server at several connection levels. For a busy site, you may want to license one hundred or more simultaneous connections. A low-traffic site can be well-served by about ten connections.

The RealAudio server is well-supported by Progressive Networks, both from its Web site and by its technical support staff. For the best results, set up the server to use UDP rather than a TCP port.

Byte-range Extensions to HTTP  New client technology, such as plug-ins, takes advantage of new server technology, such as byte-range retrieval. Byte-range retrieval allows a client to request a specific set of bytes from the server document. The Internet Engineering Task Force draft specification for this feature is online at http://www.w3.org/pub/WWW/Protocols/HTTP/1.1.

Hardware Features

On an Intranet you can often assume that the connection between the client and the server supports a megabyte per second. On the Internet, however, many users access through a relatively low-speed modem. A modern 28.8Kbps modem with hardware compression and error correction can pass about 2,800 bps. An older 14.4Kbps modem can support about half that rate. When you add multimedia content to your site, remember these numbers, and remember the fact that many users will not wait more than twelve to fifteen seconds for the entire page to download.

Network Bandwidth  The key to building an effective Web site is to measure everything by an effectiveness standard. Even if a graphic were to download instantly, it is unlikely that a portrait of the organization's founder would increase a commercial organization's sales.

It is conceivable that a member of a nonprofit organization might like to have a picture of its charismatic leader-and might send in a donation based on that image. Decades of experience in the entertainment industry suggest that distributing posters of recording artists and actors brings in sales at the box office. Used in the right way, high-bandwidth content can indeed make a site more effective.

To estimate download time, you first need to estimate file size. Here's an example of how to prepare such an estimate when the content is graphical. The most common kind of graphics files, called raster files, consist of picture elements, or pixels. Each pixel has one or more bits associated with it-the more bits, the more colors or shades of gray can be packed into the pixel. The Graphical Interchange Format (GIF), the Portable Network Graphic (PNG) format, and the format proposed by the Joint Photographic Experts Group (JPEG) are all raster formats.

Suppose you are designing a page that will include high-end graphic content. You propose that the graphic be approximately two inches by three inches on a 72 dot-per-inch monitor, so your image will be about 144´216 pixels. Further, suppose that for each pixel, the file format stores 24 bits of color information. That's 3 bytes per pixel. Before compression, this file takes up 93,312 bytes and needs over a minute to download over a 14.4Kbps modem.

If a raster file contains random data (for example, if the information in a given pixel is independent of all the other pixels in the file), there is little opportunity for compression. But images are far from random. If a given pixel is set to a particular value, there is a high likelihood that the pixels around it are set to similar values.

The designers of graphics formats take advantage of this fact to build in compression. Compression of 2:1 is common; 10:1 compression is not unheard of.

Designers of raster formats can also choose to get more compression by making a format lossy. A standard developed by the Joint Photographic Experts Group, for example, computes a mathematical function that describes the pixels.

For a particular graphic, the fidelity of that function can be set very high, or it can be set low. The higher the resolution of the function (JPEG calls it "quality"), the closer the rendered image is to the original, and the larger the file is.

For many purposes, the difference between a file with very high quality and a file with moderate quality is invisible to the human eye. Thus, many JPEGs on the Web are set with medium quality to keep their size down.

The use of lossy functions explains why graphic artists are cautioned not to edit JPEG files, but, instead, to work from the original. When a JPEG file is opened, edited, and saved, the functions must be recomputed. Recomputing functions from data that has already lost some information only causes it to lose more information.

Raster formats are a natural choice for photographs or fine art. Figure 25.5 shows a JPEG of fine art from the Nikka Galleria site, http://www.dse.com/nikka.

Figure 25.5 : A JPEG of "Tattoo Stone Bird," an original work by Dempsey Crane.

Navigator supports the common raster formats (GIF, PNG, and JPEG) natively. High-end raster formats (for example, TIFF) and vector formats (for example, CGM) require plug-ins or helper applications. When you design your page, use techniques like the ones shown in this section to estimate the download time. If the download time of the total page exceeds twelve to fifteen seconds, look for ways to decrease the file size.

For example, the image shown in Figure 25.6 is in vector format, specifically CGM, and downloads in a fraction of the time that a comparable raster image would take.

Figure 25.6 : CGM graphics are stored in vector format, leading to a trememdous reduction in file size and download time.

Storage Requirements  While the principal constraint on multimedia is download time, don't ignore the file size itself. The previous section demonstrated that a single graphical image may require tens of kilobytes. Video typically puts up thirty, or even sixty, such images every second. A few seconds of video may easily occupy several megabytes. Such files take time to download, tie up space on your server, and may fill the site visitor's hard drive.

Many formats can be successfully compressed. (GIF, PNG, and JPEG all have compression built-in.) You can also reduce file size by making the content area physically smaller, and by reducing the number of bits used to store color. For example, if the two inch by three inch graphic, described earlier, was displayed at half-size (one inch by one and a half inches) the file size would plummet from 93,312 bytes to 23,328 bytes. If the color encoding is reduced from true color (24 bits) to indexed color (8 bits), the file size further drops to just 7,776 bytes. Many graphics don't require even the full 8 bits typical of indexed color systems. Experiment with fewer colors-the Web site of the Bandwidth Conservation Society, http://www.infohiway.com/faster/index.html, shows graphics which look good down to five bits. (See http://www.infohiway.com/faster/compare.html and http://www.infohiway.com/faster/compare2.html.)

Figure 25.7 : Use a thumbnail on the listing page to keep download time low.

Figure 25.8 : Images on the detail page can be larger-in this situation visitors may wait thirty seconds or so to see the photo.

Integration with HTML

HTML, of course, was designed for text and simple graphics. The latest releases of the HTML standard provides general support for multimedia "objects," but the specific syntax for loading plug-ins is browser-specific. This section shows the general HTML model, then describes the Netscape- and Microsoft-specific HTML extensions.

HTML 3.2 and the <OBJECT> Tag

HTML 3.2 is the World Wide Web Consortium's specification for HTML, developed together with the leading Internet vendors (including Netscape and Microsoft). You can find detailed information on this new specification at http://www.w3.org/pub/WWW/MarkUp/Wilbur/.

HTML 3.2's <APPLET> tag is the inspiration behind both the <EMBED> tag and ActiveX's <> tag. The <APPLET> tag was inspired, in turn, by a proposed <OBJECT> tag. That proposal is available online at http://www.w3.org/pub/WWW/TR/WD-object.html.

The <APPLET> Tag  The general syntax for <APPLET> is

<APPLET CODE= CODEBASE=... NAME=... ALT=... ALIGN=... 
WIDTH=... HEIGHT=... HSPACE=... VSPACE=...>
<PARAM >
<PARAM >
.
.
.
</APPLET>

The CODE Attribute  The CODE attribute names the class associated with this Java applet. If you're a Java user, you get this name from the person who programmed the applet. If you're the programmer, use the class for which you write,

public class xxx extends Applet

This name will also appear as the name of the file in which the applet is stored.

The CODEBASE Attribute  CODEBASE identifies the absolute path to the applet. All relative paths in the tag, including CODE, are relative to the codebase. If the CODEBASE attribute is absent, the path to the current document is used as the codebase.

The NAME Attribute  By giving the applet a name, Netscape HTML writers can use LiveConnect and JavaScript to send messages to the applet.

The ALT Attribute  If the applet cannot be loaded for any reason, the browser can display the text provided in the ALT attribute. The W3C recommends the use of the <TEXTFLOW></TEXTFLOW> tags instead of the ALT attribute. The <TEXTFLOW> tags go between the <APPLET> and </APPLET> tags. Be sure to supply alternate text in the <TEXTFLOW> tags or the ALT attribute.

Other Attributes  The attributes ALIGN, WIDTH, HEIGHT, HSPACE, and VSPACE have the meanings HTML writers have come to associate with them-ALIGN specifies the horizontal alignment. HEIGHT and WIDTH reserve a rectangle on the browser window, just as they do for the <IMG> tag. HSPACE and VSPACE give horizontal and vertical spacing, respectively, around the embedded applet.

The <PARAM> Tag  The <PARAM> tag is used to pass parameters to the Java applet. The format is

<PARAM Name=string Value=string>

Three Ways of Invoking a Navigator Plug-In

Plug-ins fit into HTML in three different ways: embedded, hidden, or full-page. While these terms are sometimes used as though they were types of plug-ins, they are actually just ways of calling the plug-in. Be aware, however, that many plug-in programmers tacitly assume that their plug-in is called a certain way. Be sure to check the documentation that comes with the plug-in, and test it thoroughly on your page.

Embedded Plug-Ins  Netscape has added the <EMBED> tag to the set of extensions recognized by Navigator. The <EMBED> tag includes the SRC attribute, so an HTML programmer can write

<EMBED SRC="http://www.some-server.com/aMovie.avi">

The browser will attempt to get the requested entity. As described earlier in this chapter (refer to "Configuring the Server and the Browser"), the server will use the file extension (.Avi) to select a MIME content type. When the server sends the Content-type header line back to the browser, Navigator will select the plug-in which handles that media type.

HTML programmers can also use the TYPE attribute of the <EMBED> tag to force Navigator to look for a plug-in to handle the specified type. The TYPE attribute makes sense when a plug-in does not need a data stream, or when the data is generated dynamically and does not have a well-defined MIME media type. To load a plug-in which is designed for a locally defined type, you can write

<EMBED TYPE="application/x-myTest>

Navigator will define a rectangle in the Navigator window to hold embedded data. The HTML programmer can use the HEIGHT and WIDTH attributes of the <EMBED> tag to specify the size of the rectangle.

The full syntax of the <EMBED> tag is

<EMBED SRC=... HEIGHT=... WIDTH=... PALETTE=[foreground | background] HIDDEN=[true | 
[ccc]false] TYPE=... UNITS=[pixels | en] PLUGINSPAGE=...>

where PALETTE is used on the Windows platform to tell the plug-in whether it can use its own palette (foreground) or must share the background palette.

UNITS specifies whether the HEIGHT and WIDTH attributes are in pixels or en. (An en is half a point.) The default is pixels.

PLUGINSPAGE specifies the page to be loaded during assisted installation if the plug-in to handle this content is not already installed on the user's machine.

In addition to these standard attributes, the plug-in programmer may specify private parameters that you can pass to the plug-in. For example, Progressive Network's RealAudio plug-in, available at http://www.realaudio.com/products/rel2.0/plug_ins/, takes such private parameters as CONTROLS, AUTOSTART, CONSOLE, and NOLABELS.

You should also add a <NOEMBED> tag after your <EMBED> tag, to instruct browsers that do not understand <EMBED> what to display. For example,

<EMBED SRC="sample.rpm" HIDDEN=true>
<NOEMBED>
<A SRC="sample.ram">Play the audio using a helper application</A>
</NOEMBED>

Navigator (2.0 and above) will ignore anything between the <NOEMBED> tags. Browsers that do not understand <EMBED> won't understand <NOEMBED> either, but they will see and understand the anchor tag (<A SRC=...>).

Hidden Plug-Ins  A plug-in may also be hidden. Use the <EMBED> tag, but specify a HIDDEN attribute. (You can say HIDDEN=true if you prefer-true is the default.)

Full-Page Plug-Ins  Sometimes you want to allocate a whole window to the plug-in content. Instead of using the <EMBED> tag, just link to the file. For example, an HTML programmer can write

Examine <A HREF="http://www.some-server.com/myFile.xyz">my file</A>

When the site user follows this link, the server looks up the MIME media type based on the xyz file extension and begins streaming the data back to the browser. Navigator looks up the media type from among its registered plug-ins-if it finds a match, it loads the plug-in and starts an instance.

Checking for a Plug-In with JavaScript  Netscape Navigator supports a client-side scripting language called JavaScript. JavaScript is thoroughly described in Chapter 41, "JavaScript." This section shows how to use JavaScript to determine whether a plug-in is available to handle a particular MIME media type.

New features in JavaScript make it easy to find out what plug-ins the user has on their machine. You can use this information to

• Warn the user about potential MIME type conflicts.
• Direct the user to the plug-in's download page from your content page.
• Offer the content in one of several formats, depending upon what MIME media types the user's computer is configured to read.

Recall that Navigator looks for plug-ins in the plug-ins subdirectory when it first starts. As each plug-in is registered, Navigator reads information from each plug-in into an array named plugins. You can read this array with client-side JavaScript. A JavaScript plugins object has four properties:

• name  The name of the plug-in
• filename  The name of the plug-in file on the disk
• description  The description of the plug-in, read from the plug-in's resources
• An array of MIME types which the plug-in can handle.

Navigator also keeps track of how many plug-ins it has registered, so you can read the length property of the plugins array itself.

If you prefer that your content be read by a plug-in named npQuux you can easily check to see if it is registered:

var myPlugin = navigator.plugins["npQuux"];
if (myPlugin)
  --the plug-in is loaded
else
  --no quux here

Not only does Navigator keep track of all registered plug-ins, it also maintains a list of which plug-in is actually assigned to handle which MIME type. (In a clever display of originality, Navigator's engineers chose to call this array mimeTypes.) Recall that this assignment is a function of load order (on Windows) or of the user's selection (on Macintosh and UNIX machines). To see if your preferred plug-in has been selected to handle your MIME type, write

var myMIMEtype = navigator.mimeTypes["application/x-quux"];
if (myMIMEtype)
  if (myMIMEtype.enabledPlugin == navigator.plugins["npQuux"])
    --all is well. Our favorite plug-in is in control, here
  else
    --this machine uses someone else's plug-in to handle _our_ type
else
  --oops. This machine can't handle our type at all. They need our plug-in.

Depending upon your organization's objectives, you have several options if you find that the user is not using your preferred plug-in:

• You can allow them to proceed. After all, they can read the content with someone's plug-in, even if it isn't the same one you use.
• You may display a warning; if they're on a Mac or UNIX machine, you can ask them to reconfigure. If they're on a Windows machine, you can suggest that they remove the offending plug-in (give them myMimetype.enabledPlugin.filename to give them the full path).
• If the user doesn't have a plug-in that can read your MIME type, you can negotiate content. Use client-side JavaScript to find a format the user's machine can read, and write an appropriate link or <EMBED> tag into the page.
• Put up a notice to the user telling them which plug-in they need, and write a link to the download site for that plug-in into the document.

Netscape LiveConnect Technology  You can use Netscape's LiveConnect technology to integrate plug-ins, Java applets, and JavaScript.

Once a page with embedded plug-ins is up, JavaScript can read the embeds array of the current page. Each element of embeds is a plug-in object. Thus, embeds[0] is associated with the plug-in which will handle the first <EMBED> tag on your page, embeds[1] is associated with the second <EMBED> tag, and so on. You can also give the plug-in a name with the NAME attribute of the <EMBED> tag. Chapter 47, "Developing with LiveConnect," describes JavaScript you can write to communicate from JavaScript back to your plug-in. That code routes messages to a Java object associated with your plug-in, addressed by the embeds array or by name.

Microsoft and ActiveX

Microsoft has designed Internet Explorer to compete head-to-head with Netscape Navigator. In many cases (for example, HTML extensions), Internet Explorer is a clone of Navigator.

With respect to plug-ins, Internet Explorer does things a bit differently than Netscape. Microsoft has released several technologies under the general name ActiveX. Two of these technologies, ActiveX documents and ActiveX controls, are direct counterparts to plug-ins. You can learn more about ActiveX documents in Chapter 51, "ActiveX Documents." ActiveX controls are described in Chapter 49, "ActiveX Controls," and Chapter 50, "Web Authoring with ActiveX Controls."

ActiveX controls are included in a Web page using tags which closely resemble the HTML 3.2 <APPLET> tag and the original <OBJECT> tag proposal. For example, you can include the ActiveX iemenu control by writing

<OBJECT id=HelloWorld 
CODEBASE="http://www.microsoft.com/workshop/iemenu.ocx#Version=4,70,0,1086"
classid="clsid:7823A620-9DD9-11CF-A662-00AA00C066D2">
<param NAME="Menuitem[0]" value="Say 'Hello'">
<param NAME="Menuitem[1]" value="2nd menu item">
</OBJECT>

Unlike plug-ins, which are designed to be cross-platform, ActiveX controls rely heavily upon the Microsoft operating system. Thus, a plug-in programmer may write a version of a plug-in for the Macintosh, Windows, and the UNIX operating system-while each plug-in will have to be compiled for its own platform, the underlying code may be quite similar.

ActiveX controls are designed to be run on Windows platforms. They are often somewhat smaller than plug-ins because they can assume that certain Microsoft code is present. Since the only browser that understands ActiveX is Microsoft Internet Explorer, the assumption that the browser is running on Windows is a safe one.

Other Ways to Add Multimedia Content

Some kinds of multimedia content are best added using JavaScript animation or Java applets. While plug-ins are specific to Navigator, and ActiveX is only supported on Microsoft's Internet Explorer, JavaScript and Java applets are supported in both browsers. Chapter 41, "JavaScript," describes the JavaScript language. The section of that chapter titled "Microsoft's JScript" provides specific information on Microsoft's interpretation of the Netscape language.

Chapter 42, "Developing Java Applets," begins a six-chapter section on Java. Chapter 44, "Java Graphics and Animation Programming," is particularly applicable-it contains a section entitled "Animation Techniques," which is useful for certain kinds of multimedia presentation.