Position paper for the Workshop "Real Time Multimedia and the Web".
Author: Kjell Øystein Arisland
The concept of "Real Time Multimedia on the Web" appears to be loosely defined in current practice as the incorporation of real time audio and video in Web pages. Discussing "Real Time Multimedia and the Web" may therefore easily degenerate into a discussion of what kind of syntax, formats and protocols the Web needs to accomplish this technical extension.
Such a technical discussion is certainly needed, and it is not the author's intention to belittle it in any way. However, we also need substantial innovation on the Web, much as what Marc Andreessen and his cohorts did at NCSA when they developed Mosaic.
This position paper takes an opposing view of what real time multimedia should be, not for the purpose of academic discussion, but mainly because the author feels that the great potential of the Web is not being developed as it should. The Web is turning into an alternative publishing medium instead of becoming the great interactive communications tool many of us want it to be.
What I am driving at can be summed up in a simple question:
"Why can't I walk in real-time through a real building on the Web, much like I can play the game "Doom" on my old 386?"
To many, the answer will be simply: "Bandwidth limitations", and they are right, of course. Yet they are also wrong.
The beauty of "Doom" and its many follow-ups were in the masterfully conceived and equally craftily engineered implementation of user-interaction, making the game-player feel like an extension of the game itself. The graphics "bandwidth" was quite limited, in that a 386 processor imposes serious restrictions on real time animation.
One may also see a parallell type of artistic mastery of the CD-ROM platform in the aestethically pleasing, yet also very engaging game "Myst". Again, the "bandwidth" is limited. Graphically, the animation is very simple, but the CD-ROM storage capacity is used successfully to atone for slow graphics.
It may be argued that the bandwidth limitations on the Web are quite different from the bandwidth limitations in presenting animated graphics on an old PC. This is, however, beside the point, which is that there is always a bottleneck somewhere, but the true artist works around it.
When will we see masterpieces of computer interactivity as innovative as Doom and Myst on the World Wide Web platform?
Soon, hopefully, but there is a need for standardization of syntax, formats and protocols to support methods for real time programmed interactivity. The term programmed interactivity is used here to denote those aspects of real time multimedia not covered by audio and video, namely programmed, animated, interactive, graphics based applications.
There may be many more good methods around that can help us achieve better real time interactivity, but the above three do work. In the CandleWeb project we have implemented these methods in the Å (pronounced "awe") language, and our results, however simple, may serve as a basis for discussion.
Simply stated, the Å language, and the CandleWeb helper application, work much like Java does, interpreting the Å language code locally on the user's own platform. In addition, the Å language has built-in animation support including graphics objects, input objects, and automatic screen updates with double-buffering. There is also a semantic mechanism called "empowered variables" which connects variables in the interpreted code to the graphics objects, so programmers can update graphics objects by just changing the values of variables.
An interesting feature of the Å language and the split between imperative code and graphics objects is that it lends itself favorably to graphical WYSIWYG authoring. In fact, implementing graphics based applications such as educational animations generally take only 1/3 of the time and produces 1/3 of the code compared to using common programming languages like "C", "Pascal" or even Java. An authoring tool called "Awethor" is available, written in Å, with some extensions to the CandleWeb client for local file read and write.
As for audio, Å has support for playing both RIFF and MIDI, and as Å is interpreted, playing can be locally controlled. Real-time standards for audio and video will certainly be incorporated in Å.
For a general introduction to the CandleWeb platform, see the paper  The paper , describes the Å language, and the full spec can be found at .
The CandleWeb application is available for most UN*X platforms and for WIN95. In recognition of the fact that most users are reluctant to download helper applications, and that the Web really doesn't need several execution platforms, we are currently implementing an Å-to-Java compiler. The compiler will make it possible to use the simple and efficient Å language to design applications that will run under Netscape and other browsers with Java support.
Real time multimedia is certainly more than real time audio and video. Animated graphics that are program controlled can be as interactive as any other media type, and as programmers, this is our own backyard we are talking about! The CandleWeb platform defines an example of primitives for animated graphics handling that could easily have been included in the Web at an earlier stage. How about it, are we going to give away our birthright to the Web as programmers to music publishers and television moguls, or are we going to enhance the Web with real time multimedia for real programmers?
Kjell Øystein Arisland is an assistant professor at the Department of informatics, the University of Oslo, Norway, and Chief Disorganizer & Administrator of CandleWeb AS (a Norwegian Corporation). Email: email@example.com or firstname.lastname@example.org