 |
In this section we outline the basic architecture of the tools. For more
information on how to use Prolog for Internet applications, see e.g. the
PiLLoW library [4].
The workbench consists of a collection of Prolog programs, most of which
are run under the Common Gateway Interface (CGI ) [9]. The CGI
is a way for the Web server to produce dynamic HTML code---instead of
just dispatching an HTML file, the server may invoke programs (stored
in special directories typically named cgi-bin) that output HTML
code on the fly. Additional information can be transmitted to the
program using environment variables. For instance, consider the
following shell script:
#!/bin/sh
script=$HOME/prolog$PATH_INFO.pl
exec sicstus -l $script 2> /dev/null
If the script is named pl and a client requests the URL
http://domain name etc./cgi-bin/pl/test
then the pl-script will be executed by the server. The
environment variable $PATH_INFO will be set to /test by
the server. Hence, the script invokes the Prolog system which consults
the Prolog program
$HOME/prolog/test.pl. If test.pl looks
as in Figure 1,
main :- write('Content-type: text/html'), nl, nl,
write(''), nl,
write('Test'), nl,
write('Hello!'), nl,
write('').
:- main.
:- halt.
Figure 1: Simple Prolog CGI -script for generating HTML code on the
fly. The initial line declares the MIME-type of information being
transmitted; in our case marked-up text.
then the script will produce the output:
Content-type: text/html
<html>
<head><title>Test</title></head>
<body>Hello!</body>
</html>
The output is piped to the server and sent to the client
that posted the original request.
As pointed out above, the server may send information to the CGI -script
using environment variables. However, also a client (such as Netscape or
Internet Explorer) may transmit data to the CGI -script using HTML
forms. The form provides a mechanism for sending attribute/value-pairs
to the server. Forms may contain several types of objects, for
instance, radio buttons, checkboxes, text fields, menus and submit
buttons. Each object can be given an attribute name and the user may
attach a value to it. The server relays this information to the script
(which is be specified as an attribute of the <forms>-tag).
There are a number of libraries (e.g. PiLLoW
[4]) for parsing the
information and turning it into an association list. In our examples we
use a predicate html_get_data/1 to parse the information and the
result is a list of attribute/value-pairs. This mechanism makes it
possible to achieve a limited form of interactivity. The client may send
data to the script via the server; the script processes the data and
outputs a new form that, when completed, invokes the same script again.
Note that the script does not preserve its state so either it has to
pass its state to the client, or store the state in a file between
invocations.
The program committee workbench consists of several software components
described in the rest of this paper. Two components were particularly
useful:
- the PC chair (PCC ) workbench for accepting and
distributing papers, for monitoring the process of reviewing and
for notifying authors of acceptance or rejection. The PCC
workbench was accessible only to the PC organizers.
- the Reviewer's workbench was accessible to all PC members. By
means of this tool each PC member is granted access to the
reviews of all papers assigned to the him. Each PC member
can see (1) which of his reviews are missing; (2) evaluation
data and the actual review from other reviewers of the papers
assigned to the member; (3) the current ranking of all
papers. In addition the tool facilitates a forum for textual
communication where the PC members assigned to a paper may get
into discussions in case of conflicting reviews.
The general scheme of both tools is as follows:
main :-
html_get_data(Form),
lookup(page, Page, Form),
write('Content-type: text/html'), nl, nl,
write('<html>'),
write('<head><title>Title</title></head>'),
write('<body>'),
webpage(Page, Form),
write('</body></html>').
webpage(a, Form) :-
write('<form action="test" method="get">'),
write('<input type="submit" name="page" value="b">'),
write('</form>').
webpage(b, Form) :-
write('<form action="test" method="get">'),
write('<input type="submit" name="page" value="a">'),
write('</form>').
:- main.
The script fetches the form data (a list a attribute/value-pairs). One
of the attributes (in the example page) specifies what
information to display. The script then outputs a common head- and
body-part after which the script branches to the appropriate
webpage/2. In most cases the webpage/2 outputs a form that
invokes the script recursively. In our example, the first definition
outputs a form with a submit button that invokes the second definition,
and the second definition produces a form that invokes the first
definition.
|
Finally we summarize the conclusions from our work;
listing pros and cons of the tools and the underlying technology.
