Ireson-Paine's Home Page
| Departamento de Informática da Universidade do Minho]
How to connect educational programs to the Web
The Web as an educational tool
How such programs work
- Web programmers distinguish "client-side" and "server-side" processing.
In server-side processing, the Web browser asks the server to run a program.
The server does, and returns the results. In client-side processing, the
browser asks the server to send it the program, and then runs it locally.
- How does data reach the server? Let's start with static pages. When
the browser requests a Web page, it sends a URL to the Internet, e.g.
The Internet uses the address part of the URL
to find the right server, and routes the
rest of the URL to it. It arrives as one line:
GET index.htm HTTP/1.0
GET is one of several possible HTTP (Web protocol) commands - it tells the
server to send back HTML corresponding to the name that follows.
is just an identifier telling the server which HTTP protocol the browser
is using. Version 1.0 is the most common, but there are others.
- The HTML below defines a form with two input fields and a Submit button,
<FORM ACTION=calculate METHOD=GET>
First number: <INPUT TYPE=TEXT NAME=a VALUE=0><BR>
Second number: <INPUT TYPE=TEXT NAME=b VALUE=0><BR>
<INPUT TYPE=SUBMIT VALUE="Add the numbers">
When the user submits this form, the server will receive the following
request (if her or she has entered the values 3 and 4 respectively):
GET calculate?a=3&b=4 HTTP/1.0
The browser sends the name after
ACTION as the new URL, and
follows it by a
? and the data from the fields as a sequence
of name=value pairs separated by
- The server can recognise from the name
the request is for a program to be run. It could then extract the data
?, and pass it to the program by writing it to
a temporary file which the program must read. Or, if there isn't much data,
via the program's command line.
- The program must write its results as HTML, naturally. This is no problem,
and provides the author with a cconvenient way to format the output. How
do these results get back to the browser? On many servers, for example
Apache, anything the program
writes to standard output will automatically be sent to the browser. On
others, such as OS/2's
GoServe, the program
has to write its results to another temporary file, and the server then
sends that back.
- (For completeness, note that there is another way to send data from
a form, the so-called "POST method". The principle is similar, and information
can be found in any document describing the "Common Gateway Interface" or CGI,
for example here.)
- The point of this section has been to show that it's easy to connect
existing non-Webbed programs to the Web.
Graph-plotting on the Web
- Be Your Own Chancellor has a "budget constraint" option.
The user can ask for a graph of gross income against net income. This is
a useful tool in understanding how workers trade-off between using their
time for leisure and using it to earn money.
- To generate the graph, the model wrote the data points into a temporary
file, as well as writing the output page. The server then called
Gnuplot, a public-domain plotting program, to generate the
graph. The graph was plotted into a temporary file, and the model
included in its output page a reference to that file.
- The technique above is OK for "single-shot" programs, where the user
submits data, gets the results of a computation, and finishes. But it does
not work for "session-type" applications.
- These are applications where the user interacts over a series of
transactions, and where the state of the user's session must be preserved
between transactions. A common example is shopping services, where the
user starts with an empty order ("shopping basket") and can add or delete
things from it at each transaction. One of the best-known is
Amazon's interactive bookshop.
- This is difficult to program, since the Web protocol gives no natural
way to distinguish different sessions. Every time the user requests a page,
e.g. by submitting a form, the browser makes a new connection with the
server, and closes it after receiving the results. It does not automatically
send any user identification. So if John and Peter both order a new
book from Amazon, how can Amazon's server tell which request is from
John and which from Peter?
- The standard solution is to embed, in every URL that refers to the
state of the session, a unique session identifier. Take Amazon as an example,
and suppose their entry page looks like this:
This page contains three links, all of which point at pages whose
content will depend on the session they belong to.
The server would allocate the user a unique session identifier when he or she
starts. It would then embed this in every URL, for example:
<B>Welcome to Amazon</B>
<LI><A HREF="http://www.amazon.com/add/474052z">Add a book to your order</A>.
<LI><A HREF="http://www.amazon.com/view/474052z">View your order</A>
<LI><A HREF="http://www.amazon.com/pay/474052z">Pay for your order</A>
Then if the user clicks on any of these links, the server will receive the
identifier, and can use it to find the state of the relevant session. This
could be stored in a database, for example.
- Note that with this technique,
every time the server receives the URL for the entry page, it will
generate a new
one with a different identifier. This means that if the user
tries returning to their original entry page, the server must (in order
to be consistent) generate a new one. If the
then followed the links in this page, he or she would get the state of the
new session identified by the identifier in these links.
To prevent this, we can use "redirection commands". When the server
generates the entry page, it does not immediately send it back. Instead,
sends the browser a command telling it to request another URL, for
The server then receives a request for this second URL, and then sends
back the entry
page. If the user then goes back to the entry page later, the server
will recognise the
new/474052z in the request, and know it
send back the same page, rather than generating a new one with a different
- Embedding state identifiers in URLs like this, it is necessary to
generate dynamically any page
with a link or form that refers to the state of the user's session. This means
that the Web-page author has to write programs to generate these pages, which
is more work and distracts attention from their content.
Numerous tools have been developed to make the task easier.
- Some of these tools are libraries, e.g. in
(a Unix string-processing language often used for writing Web server
scripts and many other systems-programming tasks).
- Others define a new programming language for writing interactive pages.
Usually, this looks like an extended version of HTM. For one
Universal Access Inc's site. Meta-HTML is
one authoring tool: others include
Web Page Compiler,
Allaire's Cold Fusion,
Apple's Web Objects and
- These tools can either be interpreters or compilers. Interpreters
have a program attached to the server that examines the source of the
Web page being sent back, and executes some commands within it.
Server-side includes are a simple example of this. They are implemented by many servers, which
recognise pseudo-HTML commands such as (for example)
<!--#include file="address.html"--> to include the contents of
the named file at that point in the Web page. This is useful for inserting
pieces of HTML that will be the same between many pages, such as company
In contrast to interpreters, compilers compile the Web page beforehand into some kind of intermediate
code, which is run by a program attached to the server. Sun's
Web Page Compiler compiles into Java.
- My Web-O-Matic is
an authoring tool which also compiles into Java. It treats Web pages as
composed of objects such as text fields. It was developed for some more
ambitious applications at the IFS (not the ones mentioned earlier), where it
might be necessary to retain the state of a large number of data-entry forms
throughout a session. Its semantics
is based on category theory and sheaves. While here, I am looking at
the use of the algebraic specification language
as a way to specify its semantics.
For more technical information on the above,
How to connect
existing educational programs
to the Web: a simple guide
some more information
on the BBC versions of the IFS models. Information
on Web-O-Matic is available from
my Web-O-Matic page.
23rd April 1998
[ Jocelyn Ireson-Paine's Home Page
| Departamento de Informática da Universidade do Minho]