Exploiting an evolutionary accident in web3D communications to integrate application components

Abstract

The Virtual Reality Modeling Language (VRML) ushered in a new era in computer graphics by providing the first international standard 3D format for the Web (web3D). Unfortunately, some who tried VRML applications found they did not work and naturally blamed the language. However, the problem often lay in the sensitivity to different client software environments of the programming interfaces used to extend VRML. In many cases, VRML applications had to be extended to include things VRML lacked, such as sophisticated user interface and interactivity, database access, multiuser support, security and system integration support. These important aspects of modern systems were added via a programming interface (PI), called the External Authoring Interface (EAI). The problem was that applications based on the EAI would not work reliably due to changes in the client environment by competitive commercial stakeholders, affecting things like the support for a required third party programming language. It is this problem that often lead to unsatisfactory user experiences, not VRML itself.Below the client battlefield radar, three small web3D functions accidentally evolved, in symbiosis with the Web, to provide an alternative integration method built on a simple but solid foundation: the Hypertext Transport Protocol (HTTP). HTTP is the protocol from which the very fabric of the Web was woven. This paper presents methods to integrate web3D application components directly via HTTP. The three web3D functions are used in combination to implement a communication cycle that makes use of persistent state stored in web services. The approach uses open standards, is portable across platforms and resilient to changes in client environment. Applications based on this approach will work more reliably on disparate end user systems and enable developers to leverage increasingly sophisticated web advances. Overview of web3D architecture and interfacesTo aid understanding of how a web3D program communicates with other programs, the conceptual architecture of an application with a web3D component and external components is shown in Figure 1. A web3D program is called a browser because it is generally viewed as a 3D web browser. The browser interprets web3D files, multimedia files or streams and presents audio-visual content as an interactive world to the user. Generally, the browser retrieves files over the Internet using HTTP. A PI can be used to communicate events between the browser and external programs. A rendering Application Programmer Interface (API) shows the world on a display device.The EAI allowed external application components to interact with a VRML scene graph. It could thereby be used as a general integration mechanism to satisfy the disparate feature demands from applications, vendors and users alike. However, the following historical discussion reveals how problems with using the EAI developed under changes wrought by market forces over the past decade. The historical review identifies three web3D functions, which though unchan...