Thinking ahead about Netscape Plug-Ins
When it comes to extending HTML to offer more content on the Web, developers and users have quite a few choices. Perhaps the two most likely options are Sun Microsystems’ Java and Netscape’s plug-ins for Navigator.
Netscape Navigator 2.0 and subsequent versions support Java and can run Java applets. Navigator also supports helper applications, which it launches when needed to deal with data Navigator can’t handle on its own. And more recently, Navigator lets users install plug-ins to do the job.
Developers may develop, and sometimes port, existing code fairly easily to the Netscape Plug-In API. Just a bit of code modification may do the trick. To take advantage of such applications within Navigator, users must simply obtain and install the plug-in version of the applications. These plug-ins can be thought of as subroutines that operate within the browser itself — without launching a helper application.
Alternatively, companies can rewrite their applications in Java — a more daunting task. The resulting applets can then be viewed automatically in Navigator (or any Java-enabled Web browser).
Plug-ins are very nice, so what’s the problem? Why use Java when a plug-in gets the job done with less effort?
Paradigm split
The computing universe is separating itself into two paradigms: Desktop-centric computing, and network-centric computing.
In desktop-centric computing, computing as most have known it for the last decade, the software and the data are artificially separated. The user interacts with the data from a static desktop environment, and data formats need to be anticipated in order to interpret the data. You need a JPEG viewer before you can view a JPEG file, for example.
This may work satisfactorily in a closed environment, but on the Internet it’s a problem. There is really no way of knowing what you’ll find until you find it.
Most of the Netscape plug-ins belong to the familiar class of translator utilities and document viewers that permit a Babble of content types to coexist (often uncomfortably) on the same desktop. The philosophy seems to be, “If you can’t always know the formats in advance, prepare yourself for all the eventualities you can think of, and hope for the best.”
There is, for example, a Netscape plug-in called Figleaf Inline (from Carberry Technology/EBT) that lets you dynamically zoom, pan, and scroll many image formats, including CGM, GIF, JPEG, PNG, TIFF, CCITT GP4, BMP, WMF, EPSF, Sun Raster, and RGB.
Jumping through hoops
If you are a content provider and want to display, flip, and rotate vector graphics on your Web site, which format should you choose? You could depend on users to handle your format with the aforementioned plug-in. But if you do, you sharply narrow your “unprepared” audience by requiring that they pause to first determine the prerequisite plug-in, locate and obtain it, and then install it before seeing your content. Not everybody has one of these plug-ins, and some plug-ins aren’t available for all types of computers and operating systems. Since typically much of the traffic on the Web is unplanned, you can expect many visitors surfing your site will move on rather than jump through hoops.
Now suppose that the users really, really want to see your content. They could buy the Figleaf plug-in. But currently, Figleaf works only on Windows 95 or Windows NT. By purchasing Figleaf, users end up paying for at least 11 translators they don’t need to view your Web site’s content. And, if you decide to change the format from CGM to, say, IGES, the occasion will be celebrated in the traditional manner: Users will obtain and install new software — or simply not view your content.
Network-centric world
In the network-centric world, though, software and data can stay together. If you buy or write a Java applet to display the vector graphics and make the applet available at your Web site along with the data, the format could be CGM, DXF, IGES, HPGL, or perhaps something you made up. The format changes only if and when you want it to. You need not even notify the users about bug fixes and upgrades — just change the applet on your server. You won’t need to change the data to fit the latest standard unless it suits you. And now your audience has no hoops to jump through, so long as they have a Java-aware browser such as Navigator 2.0
A good example of the network-centric model in action can be seen at the BulletProof Corp. Web site. When a Java-aware browser automatically loads this applet, users may then perform various types of analysis on selectable time series of financial data and view the results graphically. The graphs and charts users see on their computer screens are not generated on the server and then loaded up to the browser; they are generated using the client CPU, just like shrink-wrapped software. But users do not need to research, buy, or install a financial software package or plug-in to display the high-quality graphics, or to communicate with the ODBC database back end.
It will be difficult to keep desktop users down on the plug-in farm once they learn that Java applets let them get to content easily and seamlessly, without direct software purchase, software installation, or plug-ins. Without worrying about standards, formats, or even about what the Java applet executing on their browser is called. And the ranks of these desktop expatriates will be swelled by new computer users with “Internet PCs,” who won’t know or care what an operating system is, or how helper apps and Netscape plug-ins should be found and installed. These new users don’t just represent the “Joe Six-pack” market, but include high-end consumers such as doctors, lawyers, and many of our parents and grandparents who were never fully engaged by the desktop revolution.
The software developers who develop plug-ins for Navigator have, in a manner of speaking, the worst of both worlds. Unlike Java applet developers, who can write a Java applet once and be done, plug-in developers must port their plug-in product to the various platforms Navigator supports. Then they face the prospect of porting these Netscape plug-ins to other browsers. The formats may change, or become so unpopular as users move on to the latest and greatest alternative that the software product becomes unprofitable to distribute and support.
Stealing ideas
Fortunately, the list of Netscape plug-ins reads like an idea sheet for Java applet developers. Most of these plug-in tools will be subsumed by developers who realize you don’t need a million dollars and megabytes of code to create sellable software.
The plug-in developers have been granted a grace period — in part because there has been a lack of convenient Java-development tools, and in part because Java applets loaded over the net are currently prevented from reading and writing files on the client filesystem or making network connections, except to the originating host. To be fair, many of these plug-in developers are simply biding their time until they see how Java “shakes out.”
Time is running out, though. Development tools have begun to arrive, and JavaSoft expects to permit the loading and authentication of signed applet “classes” in future releases of Java. In fact, the code that will do this already sits on the shelf at Sun — held up in part by the U.S. Government’s reservations about allowing RSA encryption technology on the Internet. But when public key encryption is freely available, users may be as sure of an applet’s origin as they are when they buy shrink-wrapped software at Office Depot. (Rather than simply waiting for a change in government policy, JavaSoft is also exploring ways to expand the functionality of unauthenticated applets without compromising security.)
Boosting performance, acceptance of Java
One important question remains: “Will Java software run fast enough?” Netscape plug-ins are written in platform-specific “native code” such as C or C++, so they can execute 20 to 30 times more quickly than Java applets.
This spring, however, faster compilers for Java are just starting to emerge. Sun, Symantec, and others have announced compilers that will increase the compilation and execution speed of Java, in part, by compiling bytecodes to native code “just in time” for execution on a user’s desktop machine. Symantec is currently shipping a 32-bit JIT compiler with its Cafe IDE product. Sun says it intends to release JIT compilers for SPARC/Solaris, x86/Win32, x86/Solaris, and PowerPC/MacOS, and has said that JIT compiler speeds eventually will draw near dead-even to C/C++.
Furthermore, Java will soon be implemented in silicon. The first Java chip, picoJAVA, is expected to be available this summer for industrywide licensing. And as these chips and their successors find their way into client architectures, Java software may begin to enjoy the same sort of installed-base advantage that Intel and Microsoft have enjoyed for the last decade.
Fortunes
Old paradigms shift slowly. But technology moves quickly, and the space between the two is where fortunes are made and lost. Users and enterprises that commit to plug-in solutions often must also commit to particular desktop applications and operating systems, as well as to a particular browser, and to content that must be consistent with the plug-ins they use. Users who commit to Java, on the other hand, can avoid lots of plug-in headaches and costs and enjoy browsing and interacting with data that’s free from plug-in limitations. Applet developers may suffer some pain in the short term when porting their (dare we say) legacy applications to Java, but will reap rewards over the longer term due to more flexibility and the end of the need to port their code to various platforms.
A wise man once asked, “Who is more foolish — the fool, or the fool who follows him?” Are the plug-in developers leading the users, or is it the other way around? It probably doesn’t matter. What does matter, though, is that by ignoring the opportunity Java applets present, these developers and users may be left dancing on the desktop while the audience has moved on to a bigger and better show.
