March 30, 1998
The Blurring of the Line Between Pages and ApplicationsBy Steven L. Telleen
Q: Can you help me understand the differences between Web pages and Web applications? Also, if I am creating an application, what is the difference between using a plug-in vs. using a "helper application?"
Advisor: You're correct in recognizing that distinctions between pages and applications are becoming increasingly blurred.
A traditional HTML page consists of text and in-line graphics. However, the traditional browser also allows forms to be created and the data entered on the form to be sent to a server for processing. Using CGI scripts (and, more recently, Java), the data can interact with existing server-side applications, providing a browser interface to the application running on the server.
From the early days, Web browsers also have supported "helper applications." This is where the application already resides on the client side, and the Web server downloads a data file for that application. For example, an Adobe Acrobat document would be saved using a "dot extension" in the file name "file.pdf" that is registered in the MIME tables of both the Web server and the browser. When the file is received, the Web browser automatically starts the Acrobat application and opens the file.
A "dot extension" can be defined for any application file by entering it in the MIME table of both the Web server and the Web browser. This allows data files to be distributed over an intranet for virtually any application that runs on the clients, including homegrown applications. If the browser does not recognize the MIME type for the application to which the file belongs, or cannot find the application, it gives the user the option of saving the file to disk and opening the application manually.
The next option is the plug-in. Here the application logic is stored in the Plug-In directory on the client. It works much like a helper application, except that the application appears to run inside the browser, rather than as a separate application. In the previous example, an Acrobat plug-in would open the file in the browser window rather than requiring the full application. Plug-ins generally are built by application vendors trying to maintain their proprietary protocols, so the plug-in viewer is free, but the content-development application is a single-vendor commercial product.
This blurring of the line between applications and Web pages will only get worse. XML, the new extension to HTML, allows pages to be built that are a true mosaic of text, logic, database content, and anything else digital that one can imagine.
Many processes that historically required complex programming to transform data will be handled with "programmable" tags, much like the tags in HTML, but more flexible. HTML made the presentation of content independent from the hardware and operating-system platforms. XML now makes the structure of the content independent from its presentation.
What we are seeing happen is the "objectizing effect" of the Web. The combination of community-owned content standards and network-location transparency is allowing us to build functional objects. From our limited past experience, many people looked at objects through the lenses of traditional applications and databases, as if the concept only applied to reusable subroutines.
Instead, the traditional packaging of logic, data, and even operating systems and hardware is beginning to decompose and to be reassembled into these new packages, or objects. It probably will be some time before the "right" packaging evolves, but the process eventually will transform the way our information industries and markets are structured.