You should think about a few things before you jump into the wonderful world of Netscape Navigator plug-in development. The tools you use, the compatibility, and the performance will affect your plug-in's success in the quickly growing plug-in market. As you design your Netscape Navigator plug-in, consider the following factors:
Unlike a Java applet, a plug-in is native machine code and is not interpreted, which means that you can write a plug-in in any language that compiles to native machine code. However, there are some issues that make certain languages easier to use than others.
For example, in Windows a plug-in must be a Dynamic Link Library (DLL). The development language you use must be capable of generating a DLL code module to build a stand-alone plug-in. Many languages such as Microsoft's Visual Basic and Borland's Delphi are quite capable of generating Windows DLLs, but these languages might not be able to properly generate the special resources required for plug-ins. You might be better off using one of these high-level languages to generate an OLE library for use with a third party plug-in such as ActiveX from NCompass or OpenScape from BusinessWeb. (See Appendix B for more on these plug-ins.)
The best-documented language for Navigator plug-in development is C++. This book, along with Netscape's Plug-in SDK, uses C++ exclusively. Assembler can be used inline or in separate routines. In some cases, such as software decompression, an assembler routine might provide the performance you need. Other possibilities should be considered. Perhaps a hybrid solution using C++ to call routines implemented in other languages could work as well.
It is possible to modify this book's example code so that you can use the C language for your plug-in development. However, for the most part, modifying for C is probably harder than learning a few simple things about C++ to use it in plug-in development.
What version of Netscape's Navigator should your plug-in support? Plug-in support was introduced with Navigator 2.x. Navigator 3.x brought many new and cool features such as LiveConnect and streaming data from a plug-in to the Navigator. Can you design your plug-in so that it works with both Navigator 2.x and Navigator 3.x? What about Navigator 4.x! Your plug-in can also "turn on" more features, depending on the Navigator version under which it is running.
Be sure to check out the NPN_Version API for determining the current Navigator version. Also keep in mind that the version number returned by NPN_Version does not correspond to the Navigator version (such as 2.0, 3.0, and so on) but to the plug-in API it supports. You see more on this in Chapter 9, "Instance Initialization and Destruction."
What about network bandwidth? Is your plug-in geared toward Internet usage for cases in which a typical Internet Service Provider (ISP) is connecting users at 14.4K baud or 28.8K baud? Or perhaps you are developing a plug-in for your company's local Intranet. Intranet plug-ins, used mostly on local area networks, need not worry about slow modem connections. Multimedia audio and video formats have huge bandwidth requirements. Most of today's multimedia data throughput minimums were defined by CD-ROM speeds, not by comparatively slow Internet connections. Data compression for audio and video media types has never been more important.
Let's look at audio and how you can stream it in real-time. A common modem speed today is 14,400 bits per second. Low quality audio is generally sampled at 11,025 samples per second, using one byte per sample. A speed of 11,025 samples per second is 11,025 bytes per second, and that is 88,200 bits per second:
11,025 bytes/second * 8 bits/byte = 88,200 bits/second
How are you going to fit 88,200 bps through a 14,400 bps Internet connection? The answer, of course, is data compression.
Using the preceding numbers, a 7 to 1 compression ratio would squeak you by:
88,200 bps / 14,400 bps ~ 7
Some of today's plug-in vendors are claiming compression ratios as high as 50 to 1! This more than ample compression is obtained through the use of lossy compression, or removing some data such as dead space between words. In fact, much of what you see on the Web today uses lossy compression, such as JPEG, AVI video, and audio compression.
Remember that the preceding numbers were taken from a perfect world. You won't get 14,400 bps from a 14.4K modem. Other factors such as TCP/IP error correction, the speed of your computer, and server load also play an important part in actual throughput.
Multiplatform compatibility is a big design consideration that determines your plug-in's marketability. Although this book is geared toward Windows plug-ins, Netscape's Plug-in API was designed for platform independence. You will see how they do this in Chapter 8, "The Plug-In Application Programming Interface (API)." Great efforts were made by the Netscape development staff to keep the API set consistent across the Macintosh, UNIX, and Windows platforms. Rumors of more platforms (such as OS/2) being supported for Navigator are now coming across the Internet.
If you are a Windows developer, don't be too quick to rule out a version of your plug-in for the Macintosh and UNIX platforms. Try to develop your plug-in with an eye toward other platforms. Consider using Java in conjunction with your plug-in for a user interface. Tight integration between Java and the plug-in comes with LiveConnect as shown in Chapter 14, "LiveConnect." You should only use native operating system level APIs when there is no other recourse.
Netscape introduced LiveConnect with the release of the 3.0 Navigator. LiveConnect allows Navigator plug-ins, Java, and JavaScript to communicate with each other. How can this technology benefit your development efforts? Does it make sense to add a Java extension to your plug-in, or are you doing it strictly for the hype value?
Using Java in conjunction with a plug-in can certainly reduce your development efforts. The most dramatic reduction would occur with a Java/Plug-in applet that uses a plug-in for platform- specific duties and Java for an interactive user interface. In that case, you only have to port the hardware-dependent plug-in, while the user-interface written in Java is untouched.
Netscape's LiveConnect AVI video player is a simple example of using Java and JavaScript for the user interface and leaving the video implementation to a plug-in. The LiveConnect video player is documented in Chapter 23.
An embedded plug-in is started by the EMBED tag in the Web page's HTML code. When the plug-in is loaded, it is displayed as part of the HTML document rather than within another window. This technique is very similar to how graphics are embedded in a Web page. As you design your plug-in, you should think about which EMBED tag attributes your plug-in will support. Additionally, define new attributes that are specific to your plug-in.
The next few sections document Netscape's current EMBED tag attributes. The EMBED tag has the following syntax:
<EMBED attributes> … </EMBED>
Example HEIGHT=50
The HEIGHT attribute defines the vertical size of the plug-in window in units defined by the UNITS attribute. Default UNITS are pixels.
Example HIDDEN
The HIDDEN attribute determines whether the plug-in is visible. A value of true indicates that the plug-in is hidden and not visible. This overrides any HEIGHT or WIDTH parameters and makes the plug-in zero in size. An example of a hidden plug-in is a Web page background MIDI player (a sample in this book). Be sure to use the HIDDEN attribute to define an invisible plug-in rather than defining HEIGHT and WIDTH to zero. If you use the HIDDEN attribute with no parameters, it defaults to true.
Example PALETTE=background
The PALETTE attribute is for the Windows platform. This attribute instructs the plug-in to realize its palette as either a foreground or background palette. It is useful for embedding multiple palette-aware plug-ins in a single page. The default value is background.
Example PLUGINSPAGE=http://www.yourcompany.com
The PLUGINSPAGE attribute
is used by the assisted installation feature if the plug-in registered
for the MIME type of a given EMBED
tag is not found. Its argument is a standard Universal Resource
Locator (URL) that usually contains the location of the needed
plug-in.
| Note |
This attribute is not implemented in Navigator 2.x. |
Example SRC=sound.wav
The SRC attribute indicates, with its Universal Resource Locator (URL), the location of a plug-in's data file. The MIME type of this data file determines which plug-in is loaded to handle the file. Usually, the MIME type is determined by the file's extension. The EMBED tag must use either the SRC or TYPE attribute.
Example TYPE=audio/x-wav
The TYPE attribute is used instead of SRC to load a plug-in. The TYPE attribute is used for plug-ins that do not require a data file for startup. The argument for this attribute is a MIME type that maps to a plug-in. The EMBED tag must use either the SRC or TYPE attribute.
Example WIDTH=200
The WIDTH attribute defines the horizontal size of the plug-in window in units defined by the UNITS attribute. Default UNITS are pixels.
Example UNITS=en
The UNITS attribute defines which measurement units are used by the HEIGHT and WIDTH attributes. The value can be either pixels or en. pixels are the default. An en is half the point size.
It is a simple matter to add attributes for your plug-in's private use. Just put them in the EMBED command line. Navigator ignores all nonstandard attributes while parsing the HTML EMBED tag. You get any additional name=value pairs during your plug-in's NPP_New API.
For example, many plug-ins use the AUTOSTART and LOOP attributes. These attributes can be added to the EMBED tag like this:
<EMBED SRC="video.avi" WIDTH=320 HEIGHT=200 LOOP=true AUTOSTART=true>
Notice how additional private attributes can be put in the EMBED tag command line just like standard attributes. For an example of extensive use of private attributes, check out Chapter 5, "Using a Plug-In," which shows how the RealAudio plug-in uses this technique.
Your plug-in can support more than one MIME type. This feature can be really handy for plug-ins that support more than one file format. Consider Netscape's LiveAudio plug-in, which is included with Navigator 3.x. This plug-in currently supports seven different MIME types! The most popular audio formats for UNIX, Macintosh, and Windows are covered. Table 7.1 shows the MIME types, descriptions, and suffixes supported by the LiveAudio plug-in.
| audio/basicl | AU | au |
| audio/x-aiff | AIFF | aiff, aif |
| audio/aiff | AIFF | aiff, aif |
| audio/x-wav | WAV | wav |
| audio/wav | WAV | wav |
| audio/x-midi | MIDI | midi, mid |
| audio/midi | MIDI | midi, mid |
MIME contention occurs when more than one installed plug-in supports the same MIME type. The Macintosh Navigator has solved this problem by letting the user configure appropriate plug-ins for each MIME type. At the time of this writing, Windows and UNIX do not yet have this plug-in user configuration.
When designing your plug-in, you should be aware of these MIME contention issues. The best defense is a good installation program and user documentation until Netscape resolves this problem.
Try to design for a streaming plug-in rather than a file-based plug-in whenever possible. A streaming plug-in processes data on a buffer by buffer basis as it is downloaded from the network. The advantages of using this design are twofold. First, your plug-in can operate in real-time such as the RealAudio plug-in. And second, your plug-in can take advantage of processing time while the data file is being downloaded.
Although it is preferred, in many cases it does not make sense to use a streaming plug-in design. Consider a plug-in that plays AVI video files. Because the AVI format was designed for CD-ROM streaming at 150KB per second (not your common Internet connection speed), it is not possible to play this file format in real-time over the Internet. As you will see with Netscape's AVI player plug-in example, this type of plug-in is file-based.
Navigator 3.x enables you to stream data from your plug-in to the Navigator. Do this by creating a new stream with NPN_NewStream, writing to it with NPN_Write, and destroying it with NPN_DestroyStream. These APIs are fully documented later in this book.
Why would you ever want to do this? Maybe you could create a plug-in that reads raw data from a Web server, converts it to HTML, and streams that HTML data to the Navigator for display. For example, you could write a plug-in that displays UNIX manual pages in a nice HTML format.
Your plug-in can make Web pages on-the-fly using this technique.
With the addition of a Common Gateway Interface (CGI) program residing on the Web server, your plug-in implementation can have a true client/server design. Your CGI server back-end can do things such as database searches while the browser client handles the display.
You can send data to your CGI program with NPN_GetURL or NPN_PostURL. Navigator 3.x adds NPN_GetURLNotify, NPN_PostURLNotify, and NPP_URLNotify to the mix for better error checking.
Be sure to check out the Server CPU Monitor sample for an example of using these APIs with a CGI program.
This chapter gave you some ideas to contemplate while designing your plug-in. Navigator compatibility, development languages, bandwidth requirements, LiveConnect, EMBED attributes, and MIME types should all be considered for your plug-in's development and design. Streaming plug-ins are generally considered much cooler than file-based plug-ins. You can use a CGI program for any needed server software.
The best way to get ideas for your plug-in is from existing plug-ins that are already written. Check out Appendix B and try to get one example of each type. Always be on the lookout for new and interesting plug-ins listed by Netscape, BrowserWatch, and other sites.
Chapter 8, "The Plug-In Application Programming Interface (API)," and Chapters 9 through 15 document all Netscape Navigator plug-in APIs up to Navigator version 3.x. Be sure to use the API index on the inside of this book's front cover to quickly locate these APIs.