Breaking Down the Browser

Adding this kind of support for XML processors may have an unexpected side effect on the browser. Opening the browser to external, in-line applications like this is a much more dramatic move than the earlier additions of plug-in architectures or even applets. The browser would be able to become much less integrated, reversing the trend of piling more and more applications into the same “browser” space. In this scenario, the browser is reduced to a communications engine and a parser, along with a framework that allows different applications to communicate and modify the element tree. The browser could still provide the interface services, if needed, and a basic set of tools for displaying text, but even those could be “outsourced” to other applications. Branding this browser and selling it would be a far harder task than marketing the current batch of integrated browsers, but it may be the logical final destination of browser development.

In this possible browser future, the presentation and interface aspects of the browser would be taken over by other applications (even miniapplications) that process elements. They would have their own presentation and interface structures, which the “browser” might continue to coordinate. Figure 11.7 provides a rough sketch of this possible browser architecture.

Figure 11.7  Multiapplication processing of parsed information.

In this model, much of the functionality that used to be in the browser is distributed across applications devoted to the processing of particular elements. They can all share a parser, a communications engine, and the same element tree, but the browser as a unit is unnecessary. The parser, engines, and element tree interface become browser services, rather than a distinct unit.

At this level, the much-discussed integration of operating system and browser is possible, although both disintegrate to a certain extent. An operating system is still needed to provide an environment for running these services, and several parts of the browser become even more important than they had been previously, but the element processing applications and the services for keeping them in sync provide a new area for applications and API development. The applications could be Java applets, ActiveX controls, or even COBOL programs—it doesn’t really matter, as long as they can communicate with the element trees and with each other. The processing applications could use Java’s Abstract Windowing Toolkit or the upcoming Java Foundation Classes, Microsoft’s Win32, or the Mac OS Toolbox. The model could work as well in any of those systems, or even an entirely new system, provided it allowed for the communication and coordination between the growing number of parts.

Why would anyone want this Hydra-headed replacement for the friendly browser? It offers a number of advantages. First, although it is actually built out of a large number of different parts, it doesn’t need to look any different to the user. A single browser window could still coordinate all these parts (and provide a nice home for a company logo). Second, it provides parsing services to a large number of potential processing applications without requiring every application to include its own parser. It provides a single interface for parsing services, allowing developers to build to a browser services API rather than choosing a parser, licensing it, and writing code that fits the parser.

This may muddy the operating systems/graphical user interface/browser waters even more than Microsoft already has, but their systems work on a somewhat different model. At present, Windows programs can use Internet Explorer as an Active X control, and Internet Explorer can provide a home for Active X controls and their data. This could, if developed further by Microsoft, develop into the shared browser services model described previously, but for now Internet Explorer remains in practice a collection of programs that communicate internally with each other as pieces but communicate to external programs as a unit. Microsoft certainly seems intent on piling as much of its browser into the operating system as possible, so this may change rapidly. Microsoft’s clients grow ever larger, demanding more resources by the year.