Java Network Programming (3rd ed) [Electronic resources] نسخه متنی

Chapter 17. Content Handlers

Content
handlers are one of the ideas that got developers excited about Java
in the first place. At the time that Java was first released,
Netscape, NCSA, Spyglass, and a few other combatants were fighting a
battle over who would control the standards for web browsing. One of
the battlegrounds was different browsers' ability to
handle various kinds of files. The first browsers understood only
HTML. The next generation understood HTML and GIF. JPEG support was
soon added. The intensity of this battle meant that new versions of
browsers were released every couple of weeks. Netscape made the first
attempt to break this infinite loop by introducing
plug-ins in
Navigator 2.0. Plug-ins are platform-dependent browser extenders
written in C that add the ability to view new content types such as
Adobe PDF and VRML. However, plug-ins have drawbacks. Each new
content type requires the user to download and install a new plug-in,
if indeed the right plug-in is even available for the
user's platform. To keep up, users had to expend
bandwidth and time downloading new browsers and plug-ins, each of
which fixed a few bugs and added a few new features.

The Java team saw a way around this dilemma. Their idea was to use
Java to download only the parts of the program that had to be updated
rather than the entire browser. Furthermore, when the user
encountered a web page that used a new content type, the browser
could automatically download the code that was needed to view that
content type. The user wouldn't have to stop, FTP a
plug-in, quit the browser, install the plug-in, restart the browser,
and reload the page. The mechanism that the Java team envisioned was
the content handler. Each new data type that a
web site wanted to serve would be associated with a content handler
written in Java. The content handler would be responsible for parsing
the content and displaying it to the user in the web browser window.
The abstract class that content handlers for specific data types such
as PNG or RTF would extend was
java.net.ContentHandler. James Gosling and Henry
McGilton described this scenario in 1996:

HotJava's dynamic behavior is also used for
understanding different types of objects. For example, most Web
browsers can understand a small set of image formats (typically GIF,
X11 pixmap, and X11 bitmap). If they see some other type, they have
no way to deal with it. HotJava, on the other hand, can dynamically
link the code from the host that has the image, allowing it to
display the new format. So, if someone invents a new compression
algorithm, the inventor just has to make sure that a copy of its Java
code is installed on the server that contains the images they want to
publish; they don't have to upgrade all the browsers
in the world. HotJava essentially upgrades itself on the fly when it
sees this new type. (James Gosling and Henry McGilton, The
Java Language Environment, A White Paper, May 1996,
http://java.sun.com/docs/white/langenv/HotJava.doc1l)

Unfortunately, content handlers never really made it out of
Sun's white papers into shipping software. The
ContentHandler class still exists in the standard
library, and it has some uses in custom applications. However,
neither HotJava nor any other web browser actually uses it to display
content. When HotJava downloads an HTML page or a bitmapped image, it
handles it with hardcoded routines that process that particular kind
of data. When HotJava encounters an unknown content type, it simply
asks the user to locate a helper application that can display the
file, almost exactly like a traditional web browser such as Netscape
Navigator or Internet Explorer, as xref linkend="ch17-35419"/
proves. The promise of dynamically extensible web browsers
automatically downloading content handlers for new data types as they
encounter them was never realized. Perhaps the biggest problem was
that the ContentHandler class was too generic,
providing too little information about what kind of object was being
downloaded and how it should be displayed.

Figure 17-1. HotJava's reaction to an unexpected content type, even though a content handler for this type is installed

A much more robust and better thought-out content handler mechanism is now available under the name JavaBeans Activation Framework. This is a standard extension to Java that provides the necessary API for deciding what to do with arbitrary datatypes at runtime. However, JAF has not yet been used inside web browsers or even widely adopted, although that shouldn't stop you from using it inside your own applications if you find it useful. See http://java.sun.com/beans/glasgow/jafl for more details.