12.2 Web Browsers and Handlers

The content- and protocol-handler mechanisms we've introduced can be used by any application that accesses data via URLs. This mechanism is extremely flexible; to handle a URL, you need only the appropriate protocol and content handlers. One obvious application is for Java-based Web browsers that can handle new and specialized kinds of URLs. Furthermore, Java's ability to load new classes over the Net means that, in theory, the handlers don't even need to be a part of the browser. Content and protocol handlers could be downloaded over the Net, from the same site that supplies the data, and used by the browser. If you wanted to supply some completely new data type, using a completely new protocol, you could make your data file plus a content handler and a protocol handler available on your Web server; anyone using a Web browser supporting Java could automatically get the appropriate handlers whenever they access your data. In short, Java lets you build dynamically extensible Web applications. Instead of gigantic do-everything software, you can build a lightweight scaffold that dynamically incorporates extensions as needed. Figure 12.1 shows the conceptual operation of a downloadable content handler in a Web browser; Figure 12.2 does the same for a protocol handler.

Figure 12.1: A content handler at work

Figure 12.2: A protocol handler at work

Sun's HotJava was the first browser to begin to provide these features. When HotJava encounters a type of content or a protocol it doesn't understand, it searches its classpath for an appropriate handler class. HotJava is built from the ground up on content and protocol handlers. Even document formats like HTML aren't privileged and built into the browser. HTML documents use the same content- and protocol-handler mechanisms as other data types--which means that HotJava could support other document formats easily. Furthermore, you can (at least in theory) use protocol and content handlers as powerful tools for creating applications, as JavaSoft has demonstrated with HotJava. Essentially, you use the protocol handler to manage a new class of URL, specific to your application--for example, a "sale" URL to manage a point-of-sale application.

Unfortunately, a few nasty flies are stuck in this ointment. Although content and protocol handlers are part of the Java API and they're an intrinsic part of the mechanism for working with URLs, specific content and protocol handlers aren't part of the API. The standard Java classes don't, for example, include content handlers for HTML, GIF, MPEG, or other common data types. Sun's JDK and all of the other Java environments do come with handlers, but these are installed on an application-level basis.

There are two real issues here:

• There isn't a standard that says that certain types of handlers have to be provided in each environment along with the core Java API. Instead we have to rely on the application to decide what kinds of data types it needs. This makes sense but is frustrating when it should be reasonable to expect certain basic types to be covered in all environments.

• There isn't any standard that tells you what kind of object the content handler should return. It's common sense that GIF data should be turned into an Image object, but at the moment, that's an application-level decision. If you're writing your own application and your own content handlers, that isn't an issue: you can make any decision you want. But if you're writing content handlers that are to be used by arbitrary applications (like HotJava), you need to know what they expect.

Furthermore, downloadable handlers are not part of HotJava 1.0. (We've been waiting a long time.) You can install them locally, as for all Java applications, but HotJava will not yet retrieve them from a remote host. And other browsers like Netscape Navigator and Internet Explorer do not directly support handlers at all. You can install them locally for use in your own applets, as with HotJava, but you cannot use them to extend the capabilities of the browser. Netscape and Internet Explorer are currently classic monolithic applications: knowledge about certain kinds of objects, like HTML and GIF files, is built in. These browsers can be extended via a plug-in mechanism, but plug-ins aren't portable and can't be downloaded dynamically over the Net. (Microsoft's ActiveX controls can be downloaded, but most are written in Visual Basic, which has serious security problems.) If you're writing applets for use in Netscape or Internet Explorer now, about all you can do is use the openStream() method to get a raw input stream from which to read data. Netscape, at least, has promised that a future release of Navigator will be written in Java. We hope then that we'll see more universal support for the power of handlers.