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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SourceClear Open
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide