As the popularity of the World Wide Web has grown in leaps and bounds, many people have been pushing the current design to do things which it was originally not intended for. Some of the deficiencies of HTML and current browser designs have been addressed by adding new markup control and new capabilities to browsers, but for the most part these only address the symptoms and not the actual cause of problems.
Interactive HTML is the outgrowth of some GIS work in the fall of 1994, which had as one of its goals that of making the resulting systems widely accessable over the Internet. The World Wide Web at that time would have been an ideal platform with which to make this happen, but for some fundamental limitations in the current WWW paradigm. While the original impetus for this work was due to that system, it has much broader applications in many areas where people are attempting to implement highly (or even moderately) interactive or data-intensive applications on the Web. These limitations can be broadly categorized into two related areas:
Introducing new functionality to browsers and HTML is very difficult, and implementing custom functionality is nearly impossible. The WWW is extremely dependent on the capabilities of the browsers in use; they are the central point of user interaction, and thus are the primary determining factor in what service providers are able to do. Exacerbating this is the wide number of platforms and browsers which are in use on the Web. While this wide distribution is one of the Web's strongest appeals, it also makes it much more difficult to deploy new capabilities, as they must be available in a significult number of the in-use browsers before they can be useful.
While these problems are not insurmountable for commonly desired extensions -- as the ongoing effort by the HTML Working group on tables, math, figures, and other needed features shows -- they make the development of more specializes capabilities nearly impossible.
The current WWW architecture incorporates a strict separation of duties -- the service provider handles requests and returns some presentable data to display, and the browser presents the data to the user. While this model works well for static data (standard hypertext documents, for example), it quickly begins to break down as more dynamic Web applications are created.
The essential problem is that this model assumes that any domain-specific processing of data for presentation will happen at the server; it must supply data to the browser which is in a form generally ready to be presented to the user, because the browser can include only very general-purpose functionality for display and interaction. This causes bottlenecks at two points in the system: on the network between the server and browser, where large-grain chunks of presentation-ready data must be repeatedly sent; and at the server, where the processing for many different browser requests must be performed at a central location.
Interactive HTML tries to address these problems by making it so that servers may send control information to browsers, in the form of a custom program which is actually executed down on the browser's machine. Because a processing operation on a server can also usually be viewed as a possible capability within a browser, this solution can address both of the preceeding problems; a server can now send special code to a browser which distributes its work-load across the browsers that are accessing it, and/or which adds new interaction and display logic to the browser which is specialized for the particular data being handled. A very important point is that this paradigm is much more scalable than the current server-based model, as most of the server's workload may be distributed across the browsers which are accessing it.
| Dianne Kyra Hackborn <hackbod@angryredplanet.com> | Last modified: Wed Aug 14 16:04:56 PDT 1996 |