thrift@ti.com
Web communication is typically of a discrete nature where the browser communicates with servers via synchronous, connectionless, interactions. Here I examine a method for creating live (or asynchronous, continuous) interactions which can expand the dynamic nature of communications on the Web.
Extending Web servers and browsers to be capable of varying degrees of continuous as opposed to merely discrete interaction is being developed in such systems as The Sociable Web [1] and Virtual Places [2]. Recently, Netscape Communications has proposed a server push protocol for piping continuous data to browsers [4]. EIT has also combined Web browsers with MBONE applications, including a Media On Demand service [3].
Streams, in the context of this paper, are data objects with
indefinite temporal extent. NCSA httpd 1.3 servers can send live
streams directly to clients by means of nph (no
parsed header) scripts.
Live streams can be viewed in browsers in external (or possibly,
embedded) viewers. These viewers receive continuous streamed data
from the server until the script serving the stream exits.
The list below outlines the steps in linking to streams:
Content-type: application/x-stream-loc
NAME TYPE STREAM-URL EOS-URL
stream-loc (steam
location) provides the viewer the name, type, and location of a
stream. This output can be generated by a CGI script or by linking to
a file with a stream-loc file extension (e.g.
stl).
EOS-URL is a URL that is sent to the viewer when the
stream is terminated.
stream-loc from the server, a
viewer (external or embedded) is started which sends a request
to the server for the STREAM-URL, the output of which is
streamed to the viewer. The browser is configured by having the
following entry its .mailcap file:
application/x-stream-loc; viewstream < %s
viewstream is responsible for
STREAM-URL, and
http://server/cgi_dir/nph-stream-generator?query
Once the browser is viewing streams, it can interact with them
by sending requests to the server. Typically this can work as follows:
a CGI that is executed by an independent browser request
communicates with the nph script that is serving the
stream viewer. This can be done by any of several interprocess
communication methods (most typically, via sockets).
Web streams and communicating CGI's can be used to implement a chat facility, as shown here:
In addition to developing audio and video stream applications, the following developments are possible:
INPUT
streams. Current streams are from server to client. To be able to
stream data from client to server may require the implementation of a
METHOD="STREAM" for FORMs. In this approach,
a CGI would be receiving continuous feeds from the client (audio and
video, for example).