In this paper, we describe two types of browsers related to our research, a CAD Browser and General Purpose Browser, which we see as representing the trend in network technology over the next five years. We start with several definitions of terms which are central to our vision.
Light-weight applet
Truly a light-weight applet. Something that performs a very limited
functionality, like many of the existing Java applets on the web.
Example: A small utility to convert files of one type to another.
Data Applet
Mostly data, surrounded by a bit of code, as Mike describes in his
paper on the Java Development Environment.
We assume that the CAD browser is a dedicated distributed CAD tool whose target audience is trained engineers and designers. Further, we foresee that 3D immersive interfaces will play an important role in the CAD environment. Lastly, we expect users to be able to work on a variety of development platforms.
In order to provide a development environment for CAD engineers, we see the need for incorporation or support of system applications, such as compilers, debuggers, version control, auto-documentation, etc., into the browser. These are heavy-weight applets which are retrieved once, cached until updated versions are available, and should be run locally on users' machines. These heavey-weight applets plug into the browser, utilize its GUI, as well as its graphics and simulation capabilities. To put it more simply, the browser should have the kind of functionality equal to or exceeding that of GNU Emacs, along with an effective GUI.
Besides local heavy-weight applets, the CAD Browser would also deal extensively with remote objects, which we coin as light-weight applets and data applets. These include code, images, components, text or other forms of data that people can fetch remotely, along with any conversion software to allow the data to interact with the CAD browser. Dynamic linking, network search-and-fetch capabilities and other network communications calls could be built on top of current standards such as ftp, http and be encapsulated in our own program.
A problem with running only downloaded programs from the network is that there are many situations where programs which know something about their environment can be optimized. An example of such a situation is rendering, where a program written to take advantage of local graphics hardware offers significant speed advantages over a software rendering module. We believe that this is also the case for real-time simulations, in which access to a large amount of data must be optimized for high performance. Therefore, these features should be part of the CAD Browser, and plugin software should be written to take advantage of these functionalities whenever possible.
The CAD Browser should also have extended logging ability beyond the present history and cache files. It should support a more transaction-oriented type of event-logging such as audit trail, decision and relationship support and version control, etc. A back-end database that handles transactions, events, and searches should also be implemented, and this information would be made available graphically to the user, as well as to any number of agents.
Since we believe that the CAD environment will migrate from a 2D to a 3D environment. The CAD Browser should support not only traditional 2D input devices such as the mouse, but also the interfacing of various 3D peripheral input devices, such as Head Mounted Display, Data Glove, Polhemus Fastrak, Spaceball, etc. The list should be expanded to adopt new and prevalent technology and products in the future.
The General Purpose Browser is the Network-User-Interface (NUI) that runs on an inexpensive "JavaTerm". It has less stringent hardware requirements on the host computer than the CAD Browser. However, it should still be able to accept different 2D and 3D devices as inputs. Since this browser does not have a dedicated purpose, all the applications and data that the user interacts with will be obtained from the network and no guarantee on performance of the applications can be provided. Applications are either run within the browser interface or are built on top of the browser. It's functionalities should be a proper sub-set of the CAD Browser.
One can still load the CAD Browser from the network and run it on their JavaTerm; functionalities are preserved, but obviously this would not be an optimal/efficient way of executing the CAD software. (The CAD application can be optimized to take advantage of the general purpose browser's underlying code.)
The main purpose of developing JavaTerms is for a low-cost widespread distribution and use of the network, thereby creating positive externalities and economies of scale of users. We believe that organizations (with considerable local storage and security needs) who specialize in CAD will make use of the dedicated CAD Browser while the JavaTerm may be a commodity to the general population. This arrangement makes possible the accomodation of specific needs and requirements while maintaining a standard interface across the boundaries of the network.
Modified: December 12, 1995
Feedback: Francis Chan
(fchan@ic.eecs.berkeley.edu)