A Multimedia Presentation Toolkit for the World Wide Web

SOFTWARE—PRACTICE AND EXPERIENCE, VOL. 27(4), 425–446 (APRIL 1997)

A Multimedia Presentation Toolkit for the World Wide Web

JOHNNY WONG, SATISH RAO AND NAVEEN RAMAIAH

Department of Computer Science, Iowa State University, Ames, IA 50011, U.S.A.(email: fwong, rao, [email protected])

SUMMARY

This paper describes the design and implementation of MPRES, a Multimedia Presentation Toolkit for theWWW. The WWW has seen phenomenalgrowth overthe last couple of years.It has become a vastrepositoryof multimedia information that is accessible to virtually anyone having a browser. MPRES is a multimediapresentation system that allows a user to compose and render a presentation consisting of objects referencedby their URLs (Uniform Resource Locators). It uses the concept of dynamic documents to render on aWWW browser, a sequence of multimedia scenarios, having objects of types such as audio, image, plaintext,HTML (Hypertext Markup Language) document and animation. MPRES Author, the authoring subsystem,allows the user to interactively test and compose such a presentation, using the Netscape Navigator to collectmultimedia resources from the WWW. A presentation database stores the presentations and provides aconvenient frontend for accessing them. 1997 John Wiley & Sons, Ltd.

KEY WORDS: multimedia; presentation; WWW; dynamic documents; hypermedia

INTRODUCTION

Multimedia technology has emerged as one of the results of the application of digital elec-tronics to the fields of audio and video engineering, enabling the integration of text, sound,images and video. A multimedia presentation system is therefore one which can integrate allor most of these types of multimedia objects to derive a presentation.

A presentation is a sequence of related objects representing information that the authorwould like to provide. Authoring a presentation usually involves the packaging of existinginformation into a form that is narrative. It can be classified as a form of derivative work.Derivative work is built on previous work to create a new product that adds value by structuringprevious information and/or adding new ideas. Except for the most simple products, allhuman creations are in some way derived from previous ones. Before hypermedia technology,derivative work was created through enhancing previous work by copying and altering it tocreate new products. The World Wide Web (WWW) supports better ways to create derivativework than any previous medium. By making hyperlinks to earlier created works, authors canefficiently build on previous ideas without repeating what has already been done.

It is this capability that has prompted the selection of a WWW browser to render multimediapresentations. Most WWW browsers have the inherent ability to render multimedia objects.However, they lack features that support direct implementation of presentations, insteadproviding a general purpose set of tools that a programmer could use to configure the systemto meet his/her requirements. Dynamic documents is a powerful technique that provides theframework to implement such a presentation.

CCC 0038–0644/97/040425–22 $17�50 Received 18 August 19951997 by John Wiley & Sons, Ltd. Revised 6 August 1996

426 J. WONG, S. RAO AND N. RAMAIAH

Dynamic documents

Most Web browsers are driven by user input. The user clicks on an icon or a hyperlinkto get data or navigate through the Web. Netscape Navigator� has introduced a new featurecalled dynamic documents. This gives content creators an open-standards based mechanismto have a form of reloading without any need of user intervention, thus allowing a sequenceof scenarios to be played out.

There are several connotations to the term dynamic documents when used as Web termi-nology. Different vendors and research groups have imparted different meanings to the aboveterm. To avoid confusion regarding its usage relative to this application, some of the otherterminologies are investigated briefly.

(i) Dynamic documents implemented as scripts:1 this approach is mainly used to extendand customize existing WWW interfaces. Data that is downloaded contains a script, forexample a Tcl script, as well as information that the script needs to execute. This scriptis then turned over to its ‘viewer’ (as specified by the mailcap entry) which could be aninterpreter responsible for executing the script.

(ii) Dynamic hypertext management:2 the traditional static hypertext file structure is an overviewpage with links to more detailed information. Navigation through hypertext documents re-lies on the placement of hyperlinks within the document. This approach takes the view ofmodifying HTML and the Web browsers to provide a dynamic binding for two additionalbuttons on the browser interface that are defined by tags in the HTML documents. Theseare navigational and display management buttons for providing quick-jumps to importantsections of the user’s information domain.

Presentation requirements

A presentation is defined as a sequence of logically related objects called scenarios. Eachscenario can contain any number of related multimedia objects of types such as audio, image,Hypertext Markup Language (HTML) document, plaintext or animation. The author shouldbe able to compose a presentation by specifying certain attributes and properties that thescenarios should exhibit.

(i) Scenario: logical grouping of information. Scenarios can be thought of as slides, exceptthat they remove the single-media connotation and introduce a more dynamic nature withthe inclusion of audio and animation objects.

(ii) Temporal sequencing: actual playout of the scenarios using time driven sequencing, spec-ified by the duration of existence of the scenario, after which the next scenario is to berendered.

(iii) Audio playback: this would enable a concurrent display of the scenario and an associatedaudio, which could provide a narration or an explanation of contents of that scenario.

(iv) Spatial alignment: this would provide the author with a degree of control over the actualappearance of the text, image and other objects in the presentation. Image objects, forexample, could be aligned with respect to the text and/or other objects that are in the samescenario.

(v) Image sizing: image dimensions in the number of pixels allow the author to control itsheight and width.

� Netscape Navigator is a trademark of the Netscape Communications Corp.

A MULTIMEDIA PRESENTATION TOOLKIT 427

(vi) Object identifiers: objects are identified by Uniform Resource Locators (URLs). This allowsa presentation to be composed of objects distributed over the Internet.

(vii) Enhancements: the author could specify other enhancements such as a choice of back-ground, the attributes for the font and color of text and hyperlink anchors.

The presentation also has certain behavioral and semantic properties that are importantwhen application specific issues arise. They are as follows:

(i) Hyperlink navigation: if a presentation has an HTML object as one of its constituents, thenit should be possible for the user to leave the presentation by clicking on a hyperlink, andlater to return to the presentation (using the navigation buttons provided by the browser).

(ii) Distributed master-slave application: this could be visualized as an instructor giving ademonstration to students in a class and being able to control the presentation over notonly his own display, but also those of his students. The instructor’s presentation controllerwould then function as the master and the controllers of the students would be in theslave mode. This could be implemented using a distributed software component kit suchas Horus.3

Other implementations of presentations

There are several presentation tools already available to the WWW community. Most of themjust automate formatting and linking HTML documents into slides, and if needed convertingexisting slides from some other format to HTML.

WebSlides: a multimedia slide tool

WebSlides4 is a tool that allows a user to author multimedia slides and make them availableto the Web community as HTML documents. It consists of a markup language called PresMLand a converter tool for converting these markup tags to standard HTML documents. PresMLis used to type out the content and logical structure of the presentation. It supports bulletedlists, enumerated lists, sub-headers, and most other basic features needed for a presentation.It also includes specialized tags for presentations. A converter then automatically generatesthe HTML files for the presentation, complete with formatting, links, and an index. PresMLis thus a markup-language similar to HTML, but specialized for presentations. Some of thespecialized tags include those for specifying presentation and slide titles in addition to therespective end tags. An<ICON> tag is used for displaying images, actually getting translatedto an <IMG SRC=...> by the converter.

There are some inadequacies in WebSlides which make it unsuitable for use in the currentcontext of presentations:

(i) Adherence to PresML: there are many limitations when using PresML. For example, itis advised not to use a lot of the standard HTML tags such as for headers. This placeslimitations on how visually appealing the presentation will be, considering that new devel-opments in browsers cannot get translated until the converter tool is suitably modified.

(ii) Temporal semantics: no temporal semantics are assigned to the slides. This means thatthey are driven by user input.

(iii) Limited support of multimedia objects: automatic audio playback and objects such asanimation and other HTML documents are not supported.


(iv) Testing: this tool does not offer an interactive test and compose environment.(v) Efficiency: this scheme simply translates or converts PresML to HTML. Performance

issues faced by any presentation system are not tackled.

Distributed hypermedia presentation toolkit

The Multimedia Presentation Toolkit for a Distributed Hypermedia Environment5 was de-veloped to allow a user to compose and render a presentation consisting of multimedia objects.The objects, identified by their URLs, could be over a distributed network such as the Internet.Some of the main highlights of this toolkit include the following:

(i) Strong language support for specifying complex temporal relations between the objectscomprising the presentation.

(ii) Prefetching of objects before start of the presentation for ensuring absence of delays oncethe presentation starts.

There are several disadvantages of this approach, namely:

(i) Specialized software controls the presentation rendition. Addition of further multimediatypes such as video or audio could be difficult.

(ii) Lack of a browser interface makes the presentations unavailable to the large WWW com-munity. Users wanting to access these presentations would need to ftp and install theapplication programs. However, the portability of these programs is under question due tothe use of architecture dependent mechanisms such as the pthreads package running underthe OSF/1 operating system on DEC Alpha workstations.

Roadmap

The next section discusses some of the standards and protocols that were used to developour MPRES system, ending with a summary of their use. We then discuss the design andimplementation of the MPRES system, the authoring subsystem, called MPRES Author, andthe presentation subsystem, called MPRES Viewer, and also describe the presentation databaseand the browser frontend which provides a clean WWW interface to the user wanting to accessa presentation. Our experience of using the system is described, and we conclude the paperand provide pointers for future work.

BACKGROUND

This section describes some of the existing standards, concepts and protocols that were usedto develop the MPRES presentation toolkit.

MIME

MIME6 stands for ‘Multipurpose Internet Mail Extensions’. It is the standard for how tosend multipart, multimedia, and binary data using the Internet. Typical uses of MIME includesending images, audio, wordprocessing documents, programs, or even plain text files whenit is important that the system does not modify any part of the file during transmission. Oneof the main advantages of using MIME is that the requirements for a MIME-conformant user


agent are almost trivial, yet it provides increased functionality. (The minimal requirementsare mainly concerned with ensuring that users are not shown raw data from a MIME messageinappropriately.)

Examples of MIME Content-types can be seen later in this section.

The HTTP protocol

The Hypertext Transfer Protocol (HTTP)7 has been in use by the World-Wide Web globalinformation initiative since 1990. HTTP is an application-level protocol which is light-weightand fast enough for distributed, collaborative, hypermedia information systems. It is a generic,stateless, object-oriented protocol which can be used for many tasks, such as name servers anddistributed object management systems, through extension of its request methods (commands).A feature of HTTP is the typing and negotiation of data representation, allowing systems tobe built independently of the data being transferred. Messages are passed in a format similarto that used by Internet Mail and the Multipurpose Internet Mail Extensions (MIME).

The GET method is used to retrieve whatever information (in the form of an entity) isidentified by the Request-URI. If the Request-URI refers to a data-producing process, it is theproduced data which shall be returned as the entity in the response and not the source text ofthe process (unless that text happens to be the output of the process).

Dynamic documents

The idea of dynamic documents is central to the MPRES tool. This technique has beenimplemented by the Netscape Navigator 1.1, and is not available on other browsers such asthe NCSA Mosaic and Lynx.

So far, the general idea is that browsers have always been driven by user inputs such asclicking on a link or an icon. However, the ability for the server to push new data down tothe browser was lacking till Netscape gave content creators two complementary standards formaking this work.8

(i) Server push: the connection between the browser and the server is left open till the serverexplicitly terminates the connection. The server has the ability to push data whenever itwants to. The browser displays this data but leaves the connection open for further serverpush.

(ii) Client pull: the server sends down a chunk of data, including a directive (in the HTTPresponse or the document header) that says ‘reload this data in 5 seconds’ or ‘go load thisother URL in 10 seconds’ After the specified amount of time has elapsed, the client doeswhat it was told – either reloading the current data or getting new data.

In server push, an HTTP connection is held open for an indefinite period of time (until theserver knows it is done sending data to the client and sends a terminator, or until the clientinterrupts the connection). In client pull, HTTP connections are never held open; rather, theclient is told when to open a new connection, and what data to fetch when it does so.

The server push technique uses MIME encoding (a variant of the MIME message format‘multipart/mixed’), which lets a single message (an HTTP response in this case) contain manydata items. The client pull is accomplished by an HTTP response header (or an equivalentHTML tag) that tells the client what to do after a specified time delay.

Considering the size and the traffic on the internet, network delay is a key factor when itcomes to interactive presentations. The concept of prefetching is one of the ways by which


we can avoid network delay from plaguing the presentaion. When the prefetch option is used,the presentation tool gets all the data needed for the entire presentation and stores it on thelocal disk before it actual starts presenting. Because of this, even though there might be abigger delay before the starting of the presentation, once started the presentation will go onand complete with no delays in between.

Client pull

A simple use of client pull is to cause a document to be automatically reloaded on a regularbasis. The document shown below, say ‘doc1.html’ reloads itself every one second:

<META HTTP-EQUIV="Refresh" CONTENT=1><title>Document ONE</title><h1>This is Document ONE!</h1>Here’s some text. <p>

The META tag (a standard HTML 3.0 tag, for simulating HTTP response headers in HTMLdocuments) tells the browser that it should pretend that the HTTP response when ‘doc1.html’was loaded included the following header:

Refresh: 1

This HTTP header, in turn, tells the browser to go reload (refresh) the document after 1second has elapsed. If we wanted to wait 12 seconds instead, we could have used this HTMLdirective:

<META HTTP-EQUIV="Refresh" CONTENT=12>

Some of the advantages of this method are as follows:

(i) Another document can be reloaded in n seconds in place of the current document byspecifying an HTTP response header that looks like this:Refresh: 12; URL=http://foo.bar/blatz.html

The corresponding META tag would be:<META HTTP-EQUIV="Refresh" CONTENT="12; URL=http://foo.bar/blatz.html">

(ii) A ‘Refresh’ header can be returned as part of any HTTP response, including a redirection.So a single HTTP response can say ‘go get this URL now, and then go get this other URLin 10 seconds’.

Server push

Server push is the other dynamic document mechanism, complementing client pull. Incontrast to client pull, server push takes advantage of a connection that’s held open overmultiple responses, so the server can send down more data any time it wants. The obviousadvantage is that the server has total control over when and how often new data is sent down.This method is also more efficient, since new HTTP connections do not have to be opened all


the time. The downside is that the open connection consumes a resource on the server sidewhile it is open (only when the server knows it wants this to happen, though).

The server push uses a variation of the standard MIME ‘multipart/mixed’, called ‘multipart/x-mixed-replace’, which looks like the following:

Content-type: multipart/x-mixed-replace;boundary=ThisRandomString

--ThisRandomStringContent-type: text/plain

Data for one object

--ThisRandomStringContent-type: text/html

<h4>Data for one more object.<p>Notice that this object has a different content type.<p>So the server push works with objects of different types.<p>This happens to be the last object.<p></h4>

--ThisRandomString--

The above message contains two data blocks, one of type ‘text/plain’ and the other of type‘text/html’. The final two dashes after the last occurrence of ‘ThisRandomString’ indicate thatthe message is over; there is no more data.

The ‘x-’ indicates that this is not yet a standard (only experimental). There is also a differencein the semantics associated with this new type. The ‘replace’ indicates that each new datablock will cause the previous data block to be replaced and new data will be displayed insteadof (not in addition to) the old data.

The browser deals with this MIME type in the following manner:

(i) Messages are composed using a unique boundary line that separates each data object. Eachdata object has its own headers.

(ii) Each data object replaces the previous data object. The browser gets rid of the first dataobject and instead displays the second data object.

(iii) The current data block (document) is considered finished when the next message boundaryis found.

The common gateway interface

The Common Gateway Interface (CGI)9 is a standard for interfacing external applicationswith information servers, such as HTTP or Web servers. A plain HTML document that theWeb daemon retrieves is static, which means it exists in a constant state: a text file thatdoes not change. A CGI program, on the other hand, is executed in real-time, so that it canoutput dynamic information. A CGI program is an executable, meaning that it is basicallythe equivalent of letting the world run a program on your system. This necessitates somesecurity precautions that need to be implemented. A simple mechanism would be root accessto the directory having the server programs. CGI programs can be written in any language


Figure 1. MPRES: system overview

that allows execution on the system, such as C/C++, Tcl/Tk, any Unix shell, PERL, etc. TheMPRES toolkit uses the NCSA httpd server, which acts as the presentation server entity in theMPRES presentation environment. This server is written in the C programming language. Thehttpd itself executes a standard Unix shell script which calls the presentation server program.

The presentation server of MPRES is configured as an HTTP server using the CGI spec-ification. This allows a WWW user to connect to the presentation server using the OPENcommand from his browser. He can also specify a certain number of parameters to be passedon to the server program. One of them can be the name of the presentation that he/she wishesto have rendered. Use of CGI thus gives the MPRES system a clean WWW interface. Thepresentation server uses both the server push and the client pull technique of dynamic docu-ments, using the MIME standard for bundling data. This is covered in detail in the section onthe presentation subsystem.

The presentation server also fetches the multimediaobjects from the network to local storageso that once the presentation has started, there are no further network delays. This prefetchinginvolves the use of the HTTP and details are provided in the section on the presentationsubsystem.

The MPRES system, consisting of the authoring and the presentation subsystem, whichallows a user to compose and render a presentation is discussed next.

THE MULTIMEDIA PRESENTATION SYSTEM (MPRES)

The MPRES toolkit consists of an authoring subsystem, called MPRES Author that helpsa user compose a presentation and a presentation subsystem called the MPRES Viewer thatcontrols its rendition. The specification file is the important link between the authoring andthe presentation environments. The authoring tool creates the specification file, which storesdata that the presentation subsystem needs for rendering the presentation. The relationshipbetween the two subsystems is shown in Figure 1.

When a user wishes to view or render a presentation, the presentation server is invoked


Figure 2. The MPRES authoring subsystem

and the name of the specification file is passed to it as an argument. The interface to thepresentation server is through a Web browser. When the user requests the browser to fetcha particular presentation, the request is first relayed to the presentation server, which readsthe specifications and formats its HTTP response in a way that enables the presentation to beviewed on the browser, scenario by scenario, with or without further user intervention. Thenext two subsections deal with the authoring and presentation subsystems.

MPRES Author

MPRES Author, the MPRES authoring subsystem was written in Tcl and Tk.10 An extendedversion of Tcl was used since Tcl otherwise does not provide any network I/O calls. Theauthoring subsystemis an interactive test and compose environment in which a user is providedwith a set of tools allowing him to collect a large number of multimedia resources whilenavigating through the Web. The author can then use these resources to compose a presentation,if needed specifying enhancements such as a choice of backgrounds, alignment of images andattributes for text and hyperlink anchors. Figure 2 depicts the environment of the MPRESauthoring subsystem.

As can be seen, there is a coupling between the authoring tool and the Web browser. Othercomponents used by the authoring tool include XV, the ‘viewer’ for images, and the audioplayer.

Data structures

The goal of the authoring tool is to allow the user to compose a presentation and then makeit available for rendition to the Web community. The specification file stores the informationcontent of a presentation. The authoring tool contains routines that allow the user to load, edit,


test and save the specifications. There are several global data structures that are used for thispurpose. These data structures are implemented as Tcl lists. Tcl lists have a powerful set ofsupport routines to manipulate them, making it easy for functions invoked by the load, insert,delete, save and other routines to perform operations on them:

(i) Scenario: this stores the information content of each scenario. It is a list containing thefollowing elements:

(a) Title of the scenario.(b) Duration of play of the scenario.(c) The URL for the audio (optional).(d) A list of any other objects (of image, animation, text or HTML type) making up the

scenario.(e) Selections for the background (a URL pointing to a GIF image for example), and other

attributes that set the fonts for the text and hyperlink anchors.A scenario could be given by:{ {This is an example of a title for a presentation.}

25http://www.cs.iastate.edu/˜rao/audio/myvoice.au{ {IMAGE http://www.nasa.gov/img/lc39a-logo.gif 0 250 300}

{IMAGE http://www.nasa.gov/img/mlp-logo.gif {} {} {}}{TEXT http://spacelink.msfc.nasa.gov/Spacelink/Fact.txt}

}http://www.mca.com/apollo13/phase1/gifs/background.gif#e6e8f#338b0dea#32cd32

}

(ii) Presentation: this represents an entire specification, and is implemented as a list of Sce-narios. For example:{ { {This is a title for the first scenario.}

25http://www.cs.iastate.edu/˜rao/audio/myvoice.au{ {IMAGE http://www.nasa.gov/img/lc39a-logo.gif 0 250 300}

{IMAGE http://www.nasa.gov/img/mlp-logo.gif {} {} {}}{TEXT http://spacelink.msfc.nasa.gov/Spacelink/Fact.txt}

}http://www.mca.com/apollo13/phase1/gifs/background.gif#e6e8f#338b0dea#32cd32

} /* End of first scenario */{ {This is a title for the second scenario.}

15http://www.cs.iastate.edu/˜someone/someonesvoice.au{ {ANIM http://www.netscape.com/cgi-bin/doit.cgi}

{HTML http://www.cs.iastate.edu/˜rao/sample.html}}{}{}{}


{}} /* End of second scenario */

} /* End of specification */

The above example Presentation consists of two scenarios. The second scenario has nospecial settings for the background and character attributes, as indicated by the empty lists.

Standard support routines

The MPRES Author provides a standard set of support routines that are invoked throughmenus and buttons. They are described briefly below:

(i) File operations: the File menu provides commands like Load, Save, SaveAs and Exit. TheLoad, Save and SaveAs options prompt for file names if necessary and perform read orwrite to/from the Presentations list from/to the given file. These operations deal with theentire Presentation specification.

(ii) Scenario operations: the MPRES Author toolkit displays one scenario at a time to the user.It provides options to edit contents of any of the entry fields, step to the next scenario with orwithout saving the changes to the previous scenario. It also provides navigational commandsand buttons that enable the user to move between the scenarios in the presentation, inaddition to implementing commands like ‘Delete a scenario’ or ‘Clear entry fields ofcurrently displayed scenario’. These operations deal with one scenario at a time.

(iii) Object operations: these include routines to edit object types, test the multimedia objectand insert special attributes such as image alignment, its width, height etc. Objects can alsobe inserted, deleted into scenarios using these operations.

(iv) Help: provides a brief description of the usage of various commands.(v) Import: this option is discussed next.

Collecting multimedia resources from the Web

It is understandable that a person wanting to compose a presentation regarding a particulartopic does not have the exact URLs that point to objects like GIFs or audio, etc. Instead, theauthor will probably use some search engines to find locations on the Web that have materialhe/she wants to use for composing the presentation. To facilitate retrieval from the WWW,MPRES Author is closely coupled with the Netscape browser:

(i) The Import menu option implements a Netscape to Listbox command that collects allmultimedia objects referenced in the current window of the browser into a listbox.

(ii) The user invokes the help of the listbox by pressing the right mouse button while in anentry field.

(iii) The user can then just select from the listbox any particular entry that is of interest, test itand if so desired, include it in the presentation.

To prevent the listbox from growing unmanageably large, a Purge command is providedwhich just resets the listbox entries to a null set.

An interactive test and compose environment

The MPRES Author also implements a test function, which allows the user to preview anyimage or audio object, thus getting a feel for its impact in the actual presentation. This feature


allows the author to experiment with the composition of the presentation using objects derivedfrom browsing the Web. The test function is written in C and is a feature of the extendedTcl. The algorithm for fetching objects, given the URL is explained in the later section onpresentations:

Given the MPRES Author subsystem and the corresponding set of tools, here is how a useris able to compose a presentation:

(i) The user starts up the MPRES Author and a Web browser.(ii) The user creates text files, if needed, to provide some information regarding the subject of

his presentation.(iii) The user creates some audio files to provide a narration, if needed.(iv) The user then searches the Web for information and any other data that might be of use to

him.(v) If he does find something that he wants to incorporate into his presentation, the Netscape

to Listbox command allows him to retrieve the URLs that are referenced in the currentdisplay of the browser.

(vi) The user can then test the objects to see if the context of insertion into the presentation isdesirable, or he can further edit the presentation if necessary.

(vii) The user finally saves the specifications into a file and then makes it available to the Webcommunity by storing it into the Presentation database.

MPRES Viewer

MPRES Viewer, the presentation subsystem, is a WWW interface which allows a user toaccess various options, such as, ‘play’ a particular presentation, ‘browse’ through a list ofavailable presentations stored in the presentation database and invoke the authoring tool toedit/compose presentations. MPRES Viewer has a client server architecture, as shown inFigure 3.

The httpd server

The httpd server is implemented using CGI specifications described above. It provides adirectory root for all objects referenced with URLs. A user can connect to this server byproviding the following information:

(i) The Internet address of the server and the port number.(ii) The path of the script that has to be executed (in this case the script executing the presen-

tation server).(iii) A parameter, encoded in the URL name, that gives the name of the presentation the user

wishes to render.(iv) An optional parameter having a numerical value, that provides an offset in number of lines,

for start of the first scenario. This parameter is used in the client pull technique to stepthrough the presentation scenario by scenario. Its exact usage can be seen in more detailin the paragraph dealing with the HTTP response.

(v) An optional parameter that instructs the presentation server to defer from prefetchingany objects. This is an optimization provided for the distributed master-slave applicationscenario.

As an example, consider the following URL for a presentation on Apollo 13:


Figure 3. The MPRES Viewer

http://sunfire.cs.iastate.edu:1445/cgi-bin/pres.script?APOLLO13

sunfire.cs.iastate.edu gives the Internet address of the server, 1445 is the portnumber of the server, /cgi-bin/pres.script gives the complete pathname of the scriptto be executed and APOLLO13 is the name of the presentation, provided as an argument.Arguments are specified after the ‘?’ sign.

The httpd then spawns off the presentation server, passing any arguments. It uses stdoutas its HTTP response and redirects it over the network (to the browser that established aconnection with it).

The Presentation database, developed using the Toolkit for implementing a Web front end toan Oracle database,11 can be used to retrieve URLs of presentations. It provides convenienthyperlinks to execute the presentation, relieving the viewer from the task of knowing anythingbut the name of the presentation, as stored in the database.

The presentation server

The presentation server is the central unit of the server architecture. It is called by the httpdserver, which a user connects to for playing out a presentation. The presentation server isresponsible for the following:

(i) Mapping the presentation name (provided to it as an argument by the httpd) to a specificationfile name and reading in those specifications for the current scenario to be displayed


(specified by an optional offset parameter with a default value of one).(ii) Ensuring consistency of the above specification with the definition and correctness of the

URLs identifying the objects comprising the presentation.(iii) Prefetching multimedia objects that comprise the presentation and storing them on local

disk to minimize network delays once the presentation has been started.(iv) Formulating the HTTP response that is relayed to the client by the httpd.

The Prefetch Module and the HTTP response are discussed next.

The prefetch module

The presentation server calls the prefetch module before rendering the first scenario. MPRESsupports image, text, html, audio and animation objects. All these objects, except for animationobjects, are stored as independent entities and can be referenced by URLs pointing to data files.The animation object, however, is controlled by a script using the server push technique. Thisscript might have embedded delays to control the speed of animation. Because of this delayconstraint, an object of type animation is never prefetched. All other objects are prefetchedand stored on local disk to minimize delays once the presentation has started.

The algorithm that implements the fetch module is given below:

1. Extract the IP address from the URL identifying the object. For example, ifhttp://www.cs.iastate.edu/˜rao/pic.gif is the URL, then the IP address would be theIP address associated with www.cs.iastate.edu, namely 129.186.3.1

2. Formulate an HTTP request string, using the complete path name that is extracted fromthe URL. The HTTP request string for the above example would be ‘GET /rao/pic.gif’.

3. Open a TCP socket.4. Connect to the server, using the IP address obtained from the URL.5. Transmit the HTTP request string over the TCP connection.6. Wait for the response and read the incoming data into a file on local disk.

The prefetch module simply calls the fetch algorithm for every URL present in the specifi-cation file (except if that URL represents an animation object).

Formulating the HTTP response

After having used the fetch algorithm to prefetch all the objects to local disk, the presen-tation server is ready to formulate the HTTP response. This response is an HTML documentrepresenting one scenario. Therefore, every call to the presentation server results in the gen-eration of an HTML document representing one scenario. Since the presentation server is aprogram spawned by the httpd, every call to the server architecture results in the rendition ofone scenario. Before investigating how each scenario is rendered, let us see how a completepresentation is formed.

First, the presentation is invoked by opening a URL giving the script as seen in the sectiondiscussing the httpd server. Let us consider the same example, reproduced below:

http://sunfire.cs.iastate.edu:1445/cgi-bin/pres.script?APOLLO13

(i) The client pull technique is used to play out the entire presentation, scenario by scenario.


(ii) This is accomplished by having a ‘refresh’ directive as the first header in the HTTPresponse.

(iii) This refresh directive actually instructs the client to load another URL after the specifiedtime has elapsed. For the above example, the URL in the refresh directive would be:http://sunfire.cs.iastate.edu:1445/ cgi-bin/ pres.script?APOLLO13:n

(iv) Note that this is the same as the earlier URL, except for an additional offset parameter,n.

(v) The time duration is obtained from the specification file and is the duration of existenceof the current scenario.

(vi) The value of n is so adjusted that it points to the start of the next scenario (in the list ofscenarios from the specification file). For example, if the first scenario has five objects,then the value of n would be 7 (accounting for a delimiter line).

(vii) This would result in the client connecting to the same httpd in the time specified, butthis time passing the argument n to the presentation server program.

Hence, if the current scenario was the kth line in the specification file and if the currentscenario had m objects, then the refresh directive would construct the offset parameter with avalue n, where n = k +m+ 1.

Having issued a refresh directive, the presentation server is now ready to render individualobjects. The server program uses the value of n to jump to the current scenario. If this is notspecified, it defaults to a value of 1 (this results in prefetching if it has not been suppressed). Itshould be noted that the offset parameter n is for use by the client pull technique and the useris provided with no knowledge of its existence. The offset determines the beginning of thecurrent scenario. Every URL denoting the object comprising the scenario is on a fresh line inthe specification file. The program just steps through the specification line by line, formulatingits response (rendering the objects) while doing so:

(i) Audio: if present, this is the first URL in the scenario specification. Audio clips arejust background audio which are started at the beginning of each scenario and thereis no synchronization with the graphical presentation. The audio clip could be of anylength, but it will not be meaningful if it extends beyond the time interval alloted forthat particular scenario. Audio is played out without user intervention using the MIMEmultipart/x-mixed-replace type, as in the example shown below:Content-type: multipart/x-mixed-replace;boundary=ThisRandomString

--ThisRandomString

Content-type: audio/basic

<unprintable binary data for audio obtained from local disk>

--ThisRandomString

Content-type: text/html

<Body of the HTML document that has been generated on the fly>

--ThisRandomString--


Figure 4. Relation between the presentation database and MPRES

(ii) Image: the <IMG SRC = ...> tag is used to display an image object, taking care toreference the object from the local disk. Alignment and dimensions, if specified arehandled by the ALIGN, WIDTH and HEIGHT options within this tag.

(iii) Text and HTML: displayed as is, from the local disk.(iv) Animation: the <IMG SRC = ...> tag uses the specified URL since animation objects

are not prefetched.(v) Titles and backgrounds: the <Title> and <Body background> tags are used to pro-

vide these features. This allows each scenario displayed to have a different title andbackground image (optional).

The presentation database

MPRES has a WWW interface through which it is possible for a user to query a databasewhich stores the presentations available. The query returns results from the database in theform of hyperlinks which the user can just click on to execute the presentation. In addition tobrowsing the presentation database for stored presentations, it is also possible to insert, delete,and update presentations. The relation between the WWW user interface, the presentationdatabase and the MPRES system is shown in Figure4.

The WWW interface gives the user the capability to invoke the authoring or the presentationsubsystem. The user can query the database and obtain a list of available presentations, whichhe/she can render by invoking the presentation subsystem.

The Presentation database is implemented in Oracle. Oracle is a relational database whichprovides a strong support for embedded SQL, its query language. The Frontend Toolkit11

makes all the required network calls to connect to the backend database, and uses embeddedSQL to query the database and return the results. This allowed transparent use of the databaseduring development of the MPRES system. Figure 5 shows how the frontend toolkit functions.

The following steps describe the working of this system:


Figure 5. The presentation database: system architecture

(i) A form is provided to the user with a menu of choices such as ‘Browse’, ‘Update’,‘Insert’ and ‘Delete’ presentations.

(ii) After the user submits his choice, he is prompted for the name of the presentation.(iii) The extended-GSQL module is responsible for formulating an SQL query from the user

input. An example of a query could be as follows:SELECT * FROM PRESENTATION WHERE PRESENTATION_NAME = "APOLLO13"

where APOLLO13 is the name of the presentation that the user wishes to render. Similarqueries would be formulated for the INSERT, DELETE and UPDATE operations.

(iv) The communications module is present on both the client and the server sides, and isresponsible for establishing the communication connection between the client and thedatabase server.

(v) The query that is generated from the GSQL module is passed to the database servermodule through the connection.

(vi) The database server connects to and opens the database.(vii) The server uses the query string obtained from the client to query the database.(viii) The result from this query is appropriately formatted as HTML, and the URLs asso-

ciated with the name of the presentation are converted to hyperlinks by inserting theappropriate formatting tags.

(ix) After formatting, the results are shipped over the network connection to the clientcommunication module, which then passes the data over to the client browser.

(x) The browser then displays this data as is, with the hyperlinks pointing to the URLs thatwill render the presentation.

The database stores the name of the presentation, a brief description of the subject of thepresentation and a URL that can be used to render the presentation. The presentation name isused as an index, but is non-unique, allowing more than one presentations to be stored underthe same name. This enables the user to render a presentation in several different modes,allowing for future development. Currently, only two modes are specified, one for the normalrendition as explained in the earlier section, and one with prefetching disabled. The lattermode is useful in a distributed scenario, where the master application has already prefetchedobjects, therefore the slaves have no need to so. The description field can be used to help theuser distinguish between the various modes of execution.


Summary

This section has discussed the two components comprising the presentation system, theMPRES Author and the MPRES Viewer. MPRES Author was developed with a view to allowa user to compose presentations using resources from the WWW. It offers a test and composeenvironment, which lets the author change and edit presentations as desired. Every multimediaobject can be ‘previewed’, deleted or incorporated into the presentation.

The MPRES Viewer was developed to allow rendition of the presentation on the NetscapeWWW browser. The concept of dynamic documents allows rendering without user interven-tion, and thus assigns temporal semantics to scenarios comprising the presentation. Audioplayback is achieved using the MIME multipart/x-mixed-replace type. The MPRES Vieweris configured as an httpd server using the CGI specifications.

EXPERIENCE USING THE SYSTEM

Preparing a presentation using the MPRES Author depends entirely on the time needed tosearch and accumulate information we need to include in the presentation. This depends uponthe search engine being used and the availability of the information needed on the Internet.The task of preparing the presentation can be made easier if we could maintain an objectoriented database in which we store the locations we might need for as and when we findthem, and then query the database when we need to actually prepare the presentation fromthis database and plug it in to the presentation.

Presentations which contain up to ten scenarios have been created and tested using thesystem. Preparing such a presentation took about half an hour once the object locations wereknown.

The performance of the MPRES Viewer depends on the time we need to retrieve the objectsneeded for the presentation. When the presentation is being given for the first time, the initialdelay before the presentation starts depends on the number of objects in the presentation andthe network traffic. This is because the objects are prefetched so that there is no delay in thepresentation once it starts off. On all subsequent presentations, there would be no delay at allthroughout the presentation as we have all the objects fetched and stored locally unless theprefetched objects were deleted.

Scenarios have a title associated with them and can consist objects like image, html, textand animation. The background for each of the scenarios can also be specified along with theduration the scenario is supposed to be presented before moving on to the next scenario. Toadd an object to a scenario, the author has to enter in the URL and the object type followedby clicking on the ACCEPT button provided in the Image and other object window. Anobject can be removed by selecting the object to be deleted and clicking on the DEL buttonprovided in the window. Once the author is done with a particular scenario, the author canclick on the ACCEPT provided in the main window to include the scenario in the presentation.

A sample example of how a presentation (on APOLLO13) was prepared using the systemis now given, with screen shots. Figure 6 shows the various fields provided in a typical blankform. Figures 7 and 8 show the first and the last scenarios, respectively, of a presentationwith their fields filled in. Figure9 shows the form that is popped up when the user chooses


Figure 6. Initial blank form

the BACKGROUND button. The user is given the option of providing a imagefile for thebackground of a scenario, and can also specify the attributes of the text.

CONCLUSIONS AND FURTHER WORK

The MPRES toolkit was developed with the objective that multimedia presentations shouldbe available to the WWW community for rendition. The number of users of the WWW hasgone up tremendously in the last couple of years. In fact, the WWW roughly doubles every tenweeks, with thousands of servers providing information. In June 1994, there were over 1500registered servers.12 The WWW is accessible from diverse platforms such as Windows, Macand Unix. WWW browsers are improving with leaps and bounds. Browsers such as Netscapehave new versions which provide the serious user with a lot of tools for implementingadvancedfeatures such as dynamic documents.

Summary

The MPRES system was designed to make use of these features to implement multimediapresentations. MPRES Author, the authoring tool was developed to provide the user with a testand compose environment in which he/she could provide specifications of the presentationlayout and composition. MPRES Viewer renders the presentation on the Netscape Navigator


Figure 7. First scenario

browser for the WWW. This makes the presentation available to the large WWW user com-munity through the httpd server. All that a user needs to do to have a presentation played outon his browser is to open a URL for the presentation server, specifying its name. The databaseinterface makes it even easier to access presentations.

Future work

This application could be extended to a distributed master/slave scenario, where a masterapplication would remotely control several slaves. This would be useful in a classroom contextwhere the instructor would control the master application. By giving the instructor remotecontrol of the student’s presentation, a presentation of course material could be easily rendered.This offers fascinating possibilities such as a ‘virtual classroom’, where the students couldlog on to an interactive session with the instructor and the instructor would then offer hispresentation in a broadcast mode to the entire class. A distributed software component kitsuch as Horus3 could be used as a layer over the presentation module to control the master-slave broadcasts. In fact, an attempt is currently being made to use Horus and the MPRESsystem to broadcast a presentation to a class of students.

A further addition would be to secure a separate audio channel for such a session and havea running narration by the instructor which is broadcast to all the students that are logged onto this interactive session. This last feature is outside the scope of development of the MPRES


Figure 8. Last scenario

system; however, it could be looked upon as the next direction of research and development.WWW browsers are offering increased functionality. More object types could be included

with increased support from browsers.

REFERENCES

1. M. F. Kaashoek, T. Pinckney and J. A. Tauber, ‘Dynamic documents: extensibility and adapt-ability in the WWW’, Proc. Second World Wide Web Conference ’94: Mosaic and the Web.(http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/pinckney/dd.html)

2. K. S. Oliver, C. Remenyik, A. Crosby and J. Kazmer, ‘Dynamic hypertext navigation anddisplay management’, Proc. Second World Wide Web Conference ’94: Mosaic and the Web.(http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/MedTrack/oliver/OliverRem.html)

3. H. Van Renesse and Birman, ‘Design and performance of Horus: a lightweight group communications system’,Technical Report Computer Science Department, Cornell University, August 1994.

4. T. Norderhaug, WebSlides:Authoring Slide Shows for Web Browsers.(http://www.ifi.uio.no/�terjen/PresML/)5. J. Wong and S. Srinivasan, ‘A multimedia presentation toolkit for a distributed hypermedia environment’,

Software—Practice and Experience (submitted).6. N. Borenstein, and N. Freed, Request for Comments: 1521, MIME (Multipurpose Internet Mail Extensions),

September 1993. (http://www.cis.ohio-state.edu/htbin/rfc/rfc1521.html)


Figure 9. Background setup form

7. Hypertext Transfer Protocol, HTTP/1.0 Internet Draft, Third Edition. 32nd IETF meeting, Danvers, MA,April 1995. (http://www.w3.org/hypertext/WWW/Protocols/Overview.html)

8. Netscape Dynamic Documents (http://home.netscape.com/assist/net sites/dynamic docs.html)9. Common Gateway Interface (http://www.w3.org/hypertext/WWW/CGI/Overview.html)

10. J. K. Ousterhout, Tcl and the Tk Toolkit, Addison-Wesley, Reading, MA, 1993.11. S. Magavi, J. Wong and P. Bodla, ‘Design and implementation of heterogeneous distributed multimedia

systems using Mosaic GSQL’, Software—Practice and Experience, 25(11), 1223–1242 (1995).12. WWW History. (http://www.w3.org/hypertext/WWW/History.html)

A Multimedia Presentation Toolkit for the World Wide Web

Documents

Transcript of A Multimedia Presentation Toolkit for the World Wide Web