Interactive mathematics on the Internet

        

1. Basic design principles

WIMS is designed for server-side interactivity on internet applications through http protocol. Client-side interactivity via javascript or java applets can be incorporated into Wims applications, but they usually play a secondary role.

This server-side interactivity is specially designed to support mathematical applications. It allow the use of different mathematical softwares in Wims applications.

The main objective of the project is to build a powerful system for mathematics education on the Internet. Because of the importance of practice in mathematics learning, emphasis has been put on online exercises. The system allows mathematical softwares be used either for the generation of exercises (for example the generation of random unimodular matrices of different sizes in Visual Gauss), or for the analysis of user answers (for example PARI/GP is used to compute function composition in Decomp where the solution is not unique). Softwares originally designed for local interactive use can also be adapted to power step by step exercises, for example the use of Coq (see Section 3 for detail) in Logicoq.

Mathematical softwares are also used to power online computational or visualizat ional tools, which are designed to provide online computational helps for the exercises. But these tools can also be used as stand alone ones.

These online tools on Wims have no vocation to replace traditional use of mathematical softwares. The latter is designed for heavy users to carry out complicated computations via programmed scripts, while the former is intended to `casual' users who only want to carry out `simple' computations, so that it is often not cost-effective for them to learn a whole syntax set of the software for just a few such computations. In fact, for security reasons (see Section 6), we avoid letting the user to directly type in source lines of a computational software via Wims. The security measure of the system also disallows computations requiring a long execution time.

On the other hand, web user interfaces can be made much more user friendly for the computations they support, and it is possible to create applications on Wims combining the computing power of several different softwares.

Of course, this design goal of Wims does not stop people from using it otherwise. For example, we have regularly seen people spending hours or even days on Factoris, to factor series of integers such as nm + n - 1, for n goint from 100 to 1000 and m from 2 to 10. It is clearly not the intention of Factoris to support such activities, as a direct use of PARI/GP with a small loop would give them the result within minutes. However, the fact that these people prefer spending so much time on Factoris indicates that they would have to spend more time and effort finding, installing and learning to use PARI/GP directly. Therefore we are not discouraging people from using Factoris (and other online tools) in such an intensive way.

1.1. Basic structure of the system

The center of the system is a cgi program, wims.cgi, written in C. It serves as the unique entry point for all user requests, and directs these requests to the appropriate applications.

User requests arrive at the web address of the program wims.cgi, via usual http protocol. These request may contain parameters which will be captured and interpreted by wims.cgi.

Each application under the system is an independent unit, called module. Modules are written in a proprietary scripting language, to be interpreted by wims.cgi. Inter-module communication is achieved via usual http links.

Many capabilities of the system are available to modules via special commands in this scripting language, so that these capabilities can be enhanced or upgraded without modification at the modules' level.

Each module under Wims occupies a separate directory, and contains a number of files for different purposes, written in the scripting language. A usual user request to Wims should contain information for the name of the module requested. wims.cgi will then read the files in that module's directory, and interpret them. The result is an html page generated by wims.cgi, and sent back to the user.

Our principle is to let all sophisticated mathematical computations be carried out by exterior programs, in order to gain maximal power and versatility with minimal cost of development. With this consideration in mind, wims.cgi can only carry out very basic computations by itself. When needed, the module's writer can use a special command to execute an exterior program for mathematical computations (or visualizations). wims.cgi will then call an interface to this program, which prepares the parameters, executes the appropriate program, and filters the output of the latter to make it directly exploitable by subsequent commands in the module.

The number of programs which can be executed to process one user request is limited only by the server resources. For example, in the module Factoris, a user-submitted expression is first sent to PARI/GP for a check of syntax consistency. Then the number of variables in the expression is computed. For integers or one-variable polynomials, PARI/GP is executed again to factor it. For multivariate polynomials, MuPAD is called for factorization.

Unlike mathematical computations on locally installed softwares where a program is launched for an interactive session and stays alive until the user ends the session and quits the program, programs launched by Internet accesses must terminate at the end of every process of user request. The main reason for this is that Internet users never explicitly quit a site.

To some extent, the system behaves like a special operating system, with a user interface through the World Wide Web, a programming interface through the modules' scripting language, and interfaced softwares as the system's resources.

1.2. Session control

As is necessary for server-side interactivity, session control is implemented in Wims. At each request from a new user, a session is created, with a unique session number (a 8-digit hexadecimal code) assigned to it. A directory is created at the same time, which contains all the temporary files related to the session.

One of the problems for session control is that the server has no means to know whether the user has ended the session. The only solution we have found is to keep the session alive for a certain amount of time (2 idle hours; the delay is configurable), then remove it.

There is also no means for the server to determine whether a new user is really 'new', that is, whether or not he is simply forgetting to tell the number of the session he is working under, for various technical reasons. This is not a serious problem, as the only inconvenience is a few more idle sessions which will soon be removed anyway.

We have decided not to use cookies for session control, due to compatibility considerations.

Web browsers are not designed to support intensive server-side interactivity. In particular, earlier pages stored in the browser's cache (or by proxy servers) may create considerable confusion for exercises with random parameters. There are two possible solutions to this problem.

  1. Add a unique tag to the address of each page generated by the server, in order to make the browser see different addresses at each time.

    There is a (slight) ethical inconvenience of this method, due to the fact that it `forces' the browser to uselessly store all the pages in its cache. Also, confusion will be created when the user uses `Back' button of the browser to go to an earlier page stored in the cache, then issues a (new) request to the server by following a link contained in that page. This method must not be applied when the server is contacted by an Internet robot, for otherwise the robot would never be able to stop by itself.

  2. Include a line

    <META HTTP-EQUIV="expires" CONTENT="1 Jan 1990">

    in the header of the html page, to tell the browser not to use the page stored in the cache.

    There are two inconveniences. Each time the user resizes the browser's window, a new page is requested, which may be very annoying if the user is working on an exercise with random parameters; and if the user clicks repeatedly on the `Back' button of the browser to try to quit Wims, he generates a series of useless queries to Wims, wasting the server resource.

Wims currently adopts the second solution. We have a partial solution for the `Back' button problem (simultaneous requests generate an error message), but no solution is found for the window resizing inconvenience. And we are weighing the pros and cons to see whether it is worthwhile to switch to the first solution.

1.3. Error management

Wims deals with error situations at 4 levels. At the lowest level, an unrecoverable panic generates internal error, with wims.cgi sending nothing through the Internet but registering the error on its log file.

If a bug is found in the module's script, a module-bug error is generated. An error message is sent to the http requester (user) in an unformatted manner, indicating the name of the file and the number of the line where the error is found. This is used to let the developer of the module to debug it through the Internet, without having to log on the server.

More commonly, there may be many module-independent errors in the user's request, ranging from unmatched parentheses, to invalid query string, to requests for non-existing modules, etc. These are user errors which generate a well-formatted error message indicating the nature of the error and including links for the recovery.

Finally, each module can freely define its proper error situations, and incorporate a mechanism to deal with these situations. For example, it occurs frequently that a user submits an equation where an expression is required, or vice versa. The module can detect the error by detecting the presence of the symbol `=' in the input field. In case where no guess is possible, the module sends an error message to the user, telling him to change the type of his input.

Wims is designed to support multi-language. All the error messages sent to the web interface is language-dependent, with the message's language corresponding to that chosen by the user.

1.4. Availability

The home site of Wims Wims home is freely accessible to all. An online documentation Wimsdoc can also be found there, where technical details such as the scripting language for writing modules are documented.

The source code of the system (server and modules) is downloadable from the home site, distributed under the GNU General Public License.

Although it is possible for anyone to work on a remote Wims server through the Internet, it is recommended that local installation be created if intensive work is planned, due to possibly important delay cause by network saturation. The installation of Wims itself is relatively easy (on a Linux operating system), but that of the support softwares is sometimes more complicated.