The most of WWW file transfer is currently done using http protocol.
If we replace the http protocol by file access via AFS, we will
benefit on all the advantages of the AFS, especially much faster file
transfer and intelligent caching. So, the main task is to replace
links in WWW pages by links containing the AFS location of the file.
That's done using a perl program which reads a html file and outputs
file with changed links.
Changed files can be 1) stored in paraell directory tree on the
web server or 2) created on the fly.
ad 1) advantages:
- simple
diadvantages:
- disk space requirements (a copy of every file is needed)
- periodic updates needed
ad 2) advantages:
- less disk usage on server
- no updates needed
disadvantages:
- needs java-compatible browser
- harder to implement:
Because the change of links in the file has to be done, links can
not point directly to files on the server.
The URLs, requested by clients, are not physical paths of files on
server's discs. The information, how to translate these URLs into
direct paths (we need this info to build the AFS address) is not
acessible by normal web user--so the program, which translates the
URLs, has to be run on the server.
Another problem is only http daemon can run progrtams on the server--
and we want to avoid use it. But here is one possible solution, using
simple java applet: the link points to a cgi-script on the server,
which changes the requested file (name of requested file is sent as a
parameter) and saves it in /temp directory, and sends back very short
web page, which contains nothing but one small java applet, which
loads the changed page instead of itself:
http server client
URL for cgi-script
<--------------------- user's request
cgi-script
finds and changes
requested file,
copy saves on disk,
sends back short
page with AFS address
of this file
and java applet
small page
--------------------->
browser runs
request the java applet,
<---------------------
java applet
immediately loads
AFS via AFS the page
server just saved on
requested page the server
--------------------->
and displays it
over itself in
user's browser
Because the page, sent back by http daemon is very short (about 6
lines), as well as the applet (approx. 1000B--for comparison, it's
about 1/3 the size of this paper--and it's real bytecode program!),
which is sent via AFS (so next time is taken directly from disk (or
even memory) cache), user will not usually notice this page.
For users without java on their browsers, link like
"click here" (placed in