Papers in PDF format

The server is responsible for receiving the html form containing the document, parsing it, passing the
document to ASTER and then returning ASTER's output back to the client. The server we are using is an httpd
server installed on the Rensselaer computer science network. It is running on ``Juicer'', one of the more
powerful machines at RPI (a Sparc 20 with 256 MBytes of main memory and 503 MBytes of virtual memory).
This httpd server provides ready access to clients connected to the World Wide Web through browser
applications that use the http protocol, e.g., Netscape and W3. This server allows the system administrator to
set different permissions for different users and to set restrictions such as bandwidth limitations. Most
importantly, this server has the capability to execute scripts on the local machine.
The httpd server is configured to handle scripts written in BASH as well as some executables written in Lisp, C
and Perl. BASH is used because it has better program control transfer capabilities and because some system
variables can be defined internally in BASH, whereas they must be defined externally in some other shells.
For security, the server can only execute scripts kept in a special directory. Any paths and links used by these
scripts must be given relative to this directory. This is important because several programs have to be called in
order to execute ASTER.
The first script takes the incoming html form and passes it to a parser written in Perl. The purpose of this
parser is to strip out of the form just the relevant document. The parser reads the contents of the form, checks
for any errors, and if all goes well, writes the TeX document to a file called ``/tmp/temp-msk''.
The next stage in the script sequence is to execute ASTER. ASTER is run directly from a memory image
without the emacs interface. Usually the emacs interface is used to pass the document to ASTER. However, we
used a function of ASTER which retrieves the document directly from a file so that it can be run without
emacs. The input file is ``/tmp/temp-msk'' which was created by the previous parsing step. ASTER takes this
input TeX file and returns a set of DECtalk commands that can be sent to the voice synthesizer to produce
speech output. Normally DECtalk commands are mixtures of the words to be spoken along with commands to
change pitch, speaking rate and other voice parameters. These commands are saved in another file.
The third stage in the script sequence is to return the output DECtalk commands to the client. To do this, we
define a new MIME type for ASTER. This MIME type allows the client to accept the DECtalk commands and
redirect them via the serial port to the hardware voice synthesizer.
Since the Lisp processes take some time to complete execution, depending on the document length and
complexity and the server load, it is necessary to advise the client that his/her request is being processed. For
the sighted user under X-Windows, we created a special widget which ``pops-up'' whenever the client sends a
request to be processed and advises the user that his request is being processed.
A special ``lock'' mechanism has also been incorporated into the server. This allows the system administrator
to ``lock-up'' the server when it is in use so that many people will not be using it at the same time. This is
needed because the data input and output files that are created would get overwritten if another user input his
file. The server can easily be modified to allow several users to access ASTER at once. In this case, the input
data files would simply be given a unique filename based, for example, on the pid of the individual process
handling a specific user. However, this has not been done in the current setup, since our server is not running
on a dedicated computer and this would take up too much memory and CPU processing time. Running
multiple Lisp sessions will only be suitable when a machine is dedicated entirely as an ASTER server. The
other possibility is to have a single ASTER running that takes the input from multiple users simultaneously.
We are currently working on this design.
Also it would be useful to maintain on the server a persistent data-base of ``books'' that the client could read.
The user would then select from a list of books to read or browse. These books, which would have already been
processed by ASTER, could be quickly returned to the client, enabling faster response times for the client and
lower overhead for the server.
The Web based server has been tested by users from DEC Cambridge Research Laboratory, Recordings for the
Blind, Rensselaer Polytechnic Institute and Oregon State University. The main drawback is the long response
time, which is partly due to the load on the network and partly due to the load on the server.
Telnet Interface