`WWW MEETS LINDA'' Linda for global WWW-based transaction processing systems

Werner J. Schoenfeldinger
Department for Applied Computer Science
Vienna University of Economics and Businness Administration
Email: schoenf@aia.wu-wien.ac.at


World Wide Web (W3) is a fast growing tool for providing information globally. To cope with HTML it makes applications independent from the operating system and provides them a standard interface. With CGI-scripts we experienced limitations in the application-structure. To overcome these limitations, we introduce Linda, a coordination language which coordinates the cooperation of several processes. Including Linda in W3-based applications allows a separation of input/output processing and data-processing. This new application structure creates the possiblility of W3-based front-ends for stateful transaction systems, distributed applications and different programming languages. To demonstrate, how easily Linda can be included in W3-based applications we show code samples in Perl and two example applications which have already been inplemented with Linda and W3.

Keywords: World Wide Web (W3), User Interfaces, Linda, CGI-programming, Perl


Using WWW (W3) as a front-end for applications has recently become quite popular. Starting with simple interfaces for retrieval tools such as WAIS or Archie, programmers have decided to teach their programs HTML. The reason for this trend is that a W3-based application has a wide range of advantages for programmers and users alike:

These advantages make W3 particularily attractive as a front-end for multi-user, transaction processing applications and mass information systems. However, two severe problems limit the applicability of W3 for this kind of systems:

First, the problem of secure data transmission on the network and second, the problem of integrating transaction processing with the W3-based front-end. In this paper, we suggest a uniform and general solution to the second problem: We integrate the coordination language Linda[9] with the W3 front-end and give two simple applications to illustrate the power of the approach.

WWW as a Front-End

In this section we give a brief overview about W3-based front-ends for user-applications. Starting with a short definition of the Common Gateway Interface (CGI), we describe the main parts of CGI-scripts and try to point out problems with the use of W3 as front-end via ordinary CGI-scripts.

The clear and uncomplicated structure of the gateway allows great flexibility and makes it easy to implement applications with a W3-based front-end. But due to the flexible structure of the gateway we have to deal with two major problems, namely the security problem and the consistency of transaction problems which we will discuss at the end of this section.

Common Gateway Interface

`The Common Gateway Interface, or CGI, is a standard for external gateway programs to interface with information servers such as HTTP servers''[5]

It provides the functionality for passing data between World Wide Web-Pages and programs. CGI uses for the actual data transfer both standard input and environment variables of the called process. The processing of passed data is left to the called program. The standard output of the program is returned to the HTTP-server and is immediately sent to the browser for beeing displayed. When we use CGI-scripts to process the output of HTML-forms, we can distinguish two major methods in passing data to the CGI-script[11]:

The data is passed in a CGI-specific format which is defined in [15, p.146,]. In several programming languages we can already find routines to handle and translate passed data in a suitable format for further computation.


CGI-scripts are written to perform a certain user-defined task. The task can reach from simple 'output only'-scripts to sophisticated programs. Generally, we can identify three major parts in CGI-scripts:

In most languages en-/decoding from HTML is implemented in specific library routines such as `cgi-lib.pl''[6] for Perl or `ReadParse''[18] for C++. CGI-scripts can receive data from a W3-page in several ways[19]:

It is up to the programmer to decide how data is passed. If you use another method than POST, the disadvantage is that the data string is displayed in the 'Location'-line of most browsers.

Output is given to the server via writing to STDOUT. The first output line determines the type of the output. The second line should be left blank. From the third line on, additional output can follow.

The first line must be either:

Under UNIX the CGI-program is invoked by the http-server under a specific userid and groupid. Both ids are set in the http-server configuration file. This gives the script the same access-permissions and possiblities on the system as the invoking user.

Problems and Limitations of the CGI

As pointed out in [17], the http-server is a stateless server and therefore it cannot keep any state information for running scripts. If applications require state information, the state has to be maintainted by the script. There are two methods to deal with this problem which are implemented frequently:

Both methods, however, have serious disadvantages. In using hidden attributes to store the state information, everyone can read the state information in the html-source. For some applications disclosure of the internal system state is a severe security problem.

In multi-user environments we have the problem of state-consistency. This problem arises, when the state of one client depends on the state of other clients. In this situation we have to take in consideration, that a client might crash and the state information is lost. This can lead to a deadlock in the whole application. We can find these problems in many types of applications, for example, computer games, credit card validation and credit approval, computer based exams ...

Figure 1: State information stored in pages

Using the file-system of the http-server's host as storage medium requires two things: First, the userid, under which the http-server runs must have access to an area in the file-system. On UNIX-systems, this could e.g. be /usr/tmp. Second, this implies that all necessary processes for the application have to run on the same host.

Figure 2: State information stored at the host

With NFS we can overcome this limitation in sharing the relevant data among hosts on which it is needed. In such a solution the data has to be placed in a directory, accessible by all participating hosts.

Especially for building large multi-user transaction systems W3 is an attractive front-end. Unfortunately, however, transaction processing is a major problem for W3-based applications. Today, transaction processing, process communication and synchronization, data locking,... are not supported by the existing CGI-toolbox which is available for most http-servers. It is the responsibility of the application programmer to ensure, that no conflicts and deadlocks can occur, when several users invoke CGI-scripts at the same time. Since the filesystem is the only shared media between the different CGI-processes stability for multi-user transactions can only be achieved through the lock-files and access-delays.


In this section we describe Linda, a coordination language which coordinates the cooperation of several processes. After a short introduction and a historical review, we focus on the Perl Linda Server and the Perl Linda Client[20], which we will use later for building applications.


Linda was originally developed by D. Gelernter [9] and has already prooved its usefulness for writing parallel programs [1][3][7][21]. There are several programming languages, which have been extended by Linda, such as APL[12], C[3], C++[2], Lisp, ML[21], Prolog and Perl[20].

The core of Linda is a small set of functions that can be added to a base language to yield a parallel dialect of that language. It consists mainly of a shared data collection called Tuplespace and a set of functions to access and modify the data stored in the Tuplespace. The unit of communication is a tuple, a list of typed fields which can be either actual or formal. Actual fields have a specific value whereas formal fields are placeholders for values. Tuples stored in the Tuplespace can only have actual values. Apart from the limitations of the programming language, there are no limitations for both, the number of fields in a tuple and the fieldlength. There must not be any empty fields in tuples. How tuples are represented in the Tuplespace is highly dependend on the implementation. In the Perl-Linda implementation, they are stored in encoded ASCII-text. Let us give here some examples for tuples:

In addition to storing and retrieving tuples, the Linda functions provide process synchronization. The basic functions for accessing and modifying the contents of the Tuplespace as described by [3, p.399f,] are:

To prevent deadlocks, Perl Linda has two additional commands. They are non-blocking versions of the rd() and in() commands which have been implemented in the many versions of Linda [3][1]. They are called nbin() (non-blocking in) and nbrd() (non-blocking read) and return an empty list, if no matching tuple is found. The formal fields in templates, supplied with in(), nbin(), rd() and nbrd()-functions can have wild cards, which are symbolized in Linda by the character '?'. A wild card can be matched to any other field in a tuple of the Tuplespace.

Let us illustrate, how a typical Linda-transaction between two processes takes place. Consider an example of two communicating processes shown in Table gif.

Figure 3: Two communicating processes under linda

In step 1 the clients put the tuples (x,b,2) and (a,c,4) to the Tuplespace. Client2 tries to retrieve all 3-element tuples with `b` as the second element using in(). Because there are matching tuples, they are retrieved from the Tuplespace and handed to client2. In step 4 we have an example for the blocking mechanism of in(). Tuples matching the pattern of the in()-statement given by client1 are not found in the Tuplespace, therefore client1 blocks. The tuple sent by client2 in step 5 matches the pending request from client1 and it is transfered to client1 in step 6. The following out()-statement of client2 is not sent to client1 thus it was matching the pattern. This comes because a blocking in() or rd() is satisfied with just 1 matching tuple.

The steps shown in the example are logical processing steps of the Tuplespace. There is no need for further coordination between the two Clients since in() blocks automatically until a matching tuple arrives in the Tuplespace.

Perl Linda

Perl Linda is an extension of the language Perl[22]. We have chosen Perl for the implementation of Linda because of its flexible structure and extensibility. Further, Perl has the advantage to be available on many systems, because the source code is public domain. The implementation of Linda in Perl was done in the following way:

This two-layered implementation of Linda allows clients of different programming languages running on different hosts to access the Linda-server and exchange information. The coordination is achieved by using the Linda-functions in the specific language. All Linda-clients access the data from the server in the same encoded format[20], therefore no compatibility problems between the clients of different programming languages arise.

We have already used Perl Linda for the implementation of distributed ray-tracing, distributed processing and multi user computer games. In these applications, we have learned that the Linda coordination language is a very powerful tool to coordinate several clients and the resulting client programs are considerably smaller than programs using a classical approach described in [8, p.183ff,]. Distributed Tuplespaces among several servers on different hosts have been already been developed[1][7][21][23], but have not been implemented in Perl-Linda by now.

The requirements for using the Perl Linda server is a UNIX platform, Perl 4.036 and a TCP/IP-based network. We have already tested the Linda server on several platforms such as AIX, HP-UX, LINUX, OSF1 and ULTRIX.


Since the Linda-server only handles the incoming requests from clients and stores or retrieves tuples from the Tuplespace, the processing of the tuples and transactions are left to the clients. We have developed clients for different programming languages each of which has a certain specialization:

These clients can use the interface to the Linda-server to cooperate and solve a given task. There is no need for further coordination. This is done by the intrinsic blocking mechanism of the in()- and the rd()-command which is implemented by the Linda-server. The clients do not need to run on the same host as the server, because they can connect to the Linda-server via the network.

Since data is represented in an encoded form in the Tuplespace, the application programmer generally does not need to care about data-compatibility between Linda-clients in different programming languages. Compatibility should have been achieved by the programmer of the Linda-functions in the specific language. He is the one to ensure that all data is converted from the language-specific representation to a suitable format for the Linda-server and vice versa.

The basic structure of a Linda-client looks more or less the same:

  1. The client connects to the Linda-server.
  2. Data is transferred between the client and the server. Then data is processed and the results are returned to the server. This strongly depends on the purpose of the program. For some applications only a confirmation might be needed.
  3. The client disconnects from the Linda-server. Usually the client should disconnect by sending a disconnect command. However, if the client dies, the server will notice this too.

To illustrate the usage of a sample Perl Linda, we show the example of a Linda-client for distributed counting in Figure 4 gif. Several Linda-clients count together a variable from 1 to 10000. Only one client is able to increase the variable at a time. The coordination is fully left to the clients. Although this task is not useful in itself, it represents a very good example for parallel programming and coordination.

#!/usr/local/bin/perl                        # Invoking Perl
require "linda-cli.pl";                      # Adding the Linda-library
&register_client("aig.wu-wien.ac.at", 7999); # Registration to the Linda-server
@tuple=&nbrd("COUNTBEGIN");                  # Client determines if he is 
&out("COUNT",1), &out("COUNTBEGIN")          # the first client ?
        if @tuple==();                       #
while($var<10000)                            # The count routine
{                                            #
        @tuple=&in("COUNT", "?");            # Get the actual tuple (COUNT, value)
        &printtuple(@tuple);                 # Print the whole tuple
        $var=&element("last",2,@tuple);      # Extract the value of  COUNT
        $var++;                              # Increase the value by 1
        &out("COUNT",$var);                  # Put it to the Tuplespace
}                                            #
&close_client();                             # Say good bye

Figure 4: Count-Client in Perl Linda

Restrictions of Perl Linda in Transaction Processing

The flexible structure of Linda generally allows us to easily distribute applications between different hosts and share data and work through a Linda Tuplespace[4]. Since Linda does not provide the full functionality needed for transaction management, we have to keep certain restrictions from server and clients in mind.

Bakken[1, p.289,] points out two major problems caused by a crash of the client:

Perl Linda can cope with the `lost tuple problem` in using the functions uin() and uout() which provide a recovery of the updated tuple in case of a crash of the client. A solution to the `duplicated tuple problem''has been implemented in another version of Linda[1]. This solution with atomic guarded statements which can provide atomicity for a series of out() operations. It is feasible for Perl Linda too, however, implementation is left to future work.

The second area of problems with the usage of Linda for transactions systems is the failure on the server side. To prevent data loss due to a crash on the server-side we have to solve 2 problems:

There have already been implemented a solution to both problems through replication and usage of multiple Tuplespaces[1]. In Perl Linda it is by now left to the application-programmer to equip the application with such a facility. This can be implemented via signal-handling. On the server-side is a mechanism provided to dump the contents of the Tuplespace to the local filesystem and to recover the Tuplespace from it after the restart[20].

Linda Working Together with WWW

The basic idea for supporting W3-based applications with Linda is the separation of transaction of input/output processing and data processing. With Linda, CGI-scripts are only responsible for input/output-processing, whereas the responsibility for all data-processing and transactions is shifted to background application processes, which communicate with the CGI-scripts via a Linda Tuplespace (Figure 6gif). This results in the following advantages:

In this approach we see the chance to support W3-based applications with an interface to distributed computing which is both, easy to implement - and easy to use. The inclusion of Linda in such applications provides bridges between the most popular CGI-Script language Perl and other languages in which Linda-clients already exist. These languages have their strengths in different fields, and we can build heterogenuous applications using the different languages wisely. However, Linda provides W3 with an interface meeting the Transaction Processing Standards[10, p.80,]:

Application Architecture

In a CGI-script without Linda the browser is blocking until the CGI-script has terminated. The structure of such an application is shown in Figure 5gif.

Figure 5: CGI-application without Linda

For many applications this structure is not sufficient. There are some reasons for this:

Integrating Linda in W3-based applications results in changes in the application structure. The CGI-script, in normal CGI-programs responsible for the whole functionality, is only responsible for the data-transfer to and from the Tuplespace. In addition to the transfer from the Tuplespace it has to convert the data into HTML-format.

Figure 6: W3 and Linda working together

Figure 6gif shows the typical structure of a W3-Linda application. The CGI-script interacts between the front-end and the Tuplespace. The other clients which are connected to the Tuplespace can run on different hosts and, of course, in different languages.

Data is shared via the Tuplespace with the actual application. The CGI-script waits with an in()-statement until the application puts the data in the Tuplespace. Compared to the solution without Linda, it is possible for more applications to use the data sent to the Tuplespace. This could, for example, result in a parallel search in several databases. The structure of such a application is shown in Figure 7gif. In Figures 6gif and 7gif for matters of clarity the interactions are only shown for one process but it should be clear that this application structure works for multiple requests too. If the processing of a task is very time consuming there can be added more worker-clients to the Tuplespace waiting for tasks.

Figure 7: CGI-application with Linda, waiting for task completion

Through the usage of a Linda as interconnector between front-end and application, we can develop a flexible, termination-independend structure shown in Figure 8gif.

The application simply checks the tuple-space for requests. If a request is found in the Tuplespace, it is handled. Otherwise the application sleeps for a certain amount of time in order to not exhaust the system resources. The user handles the situations in the same way. After sending the request he receives a notification that his request is being processed. Meanwhile, he can do other things and check later, if the results already have arrived. This can be done either by automatical reloading the page or simply by manual query.

Figure 8: Linda and W3, front-end is independend from application


In this section we show how the interaction between Linda and W3 is implemented. Our code examples will be in Perl, since Perl is used frequently for programming CGI-scripts. Another reason for using Perl is, that the interaction between the front-end and the Tuplespace is not time-critical. Therefore, for this class of applications Perl represents a flexible and sufficient solution for this problem.

The only requirement for the Linda-W3-based applications is, that a Linda-server is running on the chosen host and port. The server can be started by every user if the port-number is above 1024. The default port-number is 7999. The Linda Perl-libraries have to be installed in the standard Perl include-directory. Otherwise they cannot be found by the CGI-script.

The first code example shows a very simple interaction between a form and the Tuplespace. No data processing is done, only the data-transfer is implemented.

#!/usr/local/bin/perl                         # Invoking Perl
require "linda-cli.pl";                       # Adding the Linda-Library
require "cgi-lib.pl";                         # Adding the CGI-library [cgi-lib.pl] 
&ReadParse;                                   # Reading Information passed by Form
&register_client("aig.wu-wien.ac.at", 7999);  # Registration to Linda Tuplespace
for( sort keys(%in))                          # Transfering data to Tuplespace
        { &out($_, $in{$_}); }                #   in format (Name, Value)
&close_client();                              # 
print &PrintHeader;                           # http-server needs 
print "\n<h1>Data transferred</h1>\n";        #   "Content-type: text/html"

Figure 9: Data transfer from Form to Tuplespace

From this example we can see that very little code is needed to implement such a communication. This is to a great extend due to the functionality embedded in the 'required' libraries.

The next example deals with the data-transfer in the other direction. Let us consider as example a printer accounting system, in which the spooler stores the information about the printed pages in a Tuplespace. The format for this is:

e.g: (PACC,schoenf,23,542)

The printer accounting system consists of two components. First, the spoolers responsible for the printers call a tiny feeder-program which the user-data in the Tuplespace. The first item named 'PACC' is only necessary, if the Tuplespace is used by several applications. The second component is the printer accounting statistic shown in Figure 10 gif.

#!/usr/local/bin/perl                                 # Invoking Perl
require "linda-cli.pl";                               # Adding the Linda-library
require "cgi-lib.pl";                                 # Adding the CGI-library [cgi-lib.pl]
&register_client("aig.wu-wien.ac.at", 7999);          # Registration to Linda Tuplespace
@tuplelist=&nbrd(PACC,"?","?","?");                   # Transfering data from the Tuplespace
&close_client();                                      # Closing the connection to the Tuplespace
for(@tuplelist)                                       #
{                                                     #
   ($user,$day,$total) = &detrans(split(/,/, $_));    # Extracting Data from the tuples
   ($usr{$total},$pday{$total})=($user,$day);         # Preparing data for sorted output
}                                                     #
print &PrintHeader;                                   # HTML-Output
print "\n<h1>Printer Highscore</h1>\n<hr>\n<pre>\n";  # Well <pre> will do it
printf("%-15s %6s %6s\n<br>","User","Today","Total"); #
for( reverse (sort keys(%usr)))                       #
{                                                     # 
   printf("%-15s %6s %6s\n",$usr{$_},$pday{$_},$_);   #
}                                                     #
print "</pre>\n<hr>\n";                               #

Figure 10: Source of `Printer Highscore''

The examples show, that it is quite comfortable to separate the acquisition of information from the actual input/output processing. Further, the update of information does not depend on user-requests. However, an user-dependend update of information can be implemented by the application-structure shown in Figure 7 gif.

Applications with Linda and WWW

In this section we present W3-based applications which work with Linda. We present Disctool, an application which allows a system administrator to view the current usage of the harddiscs in a cluster, independend on which system he currently works. The second application is "LVA-Express", a program which implements continuous opinion polls with immediate statistical analysis of the results. This system is intended to improve the course-evaluation system at our university.


In our department we have by now a cluster of 23 UNIX-workstations. Software and applications are distributed among the harddiscs of these computers. The motivation for this application is the problem, that disc-space is a scarce ressource. Due to automatic processes (ftp-mirrors, system logs, mail, backups), it frequently happens that the disc-usage approaches 100%. In this case users on the network may not be able to save their work anymore, documents cannot be printed and cannot be received. Immediate intervention of a system administrator is required.

The current solution is that the system administrator tries to forecast disc-shortages in order to take counter measures. However, to manually check 17 systems can be a very time-consuming job, therefore we decided to build a W3-based application for this task.

To check the disc-usage on a system, the UNIX-commands 'df' and 'bdf' are used, depending on the UNIX-version. These commands result in the following output:

Filesystem     1024-blocks        Used       Avail Capacity  Mounted on
/dev/rz3a            41711       32553        4986    87%    /
/dev/rz3g           816425      693637       41145    94%    /usr
/dev/rz3d            51289       15818       30342    34%    /var
/dev/rz1c          1025374      921267      104107    90%    /disk2

Impementation based on Remote Procedure Calls (RPC)[8, p.240ff,] implies access rights for the user 'nobody', which runs the http-server. For security reasons this is an impossible situation.

So we decided to use Linda to overcome this problem. Tiny background scripts, running on every workstation in the background should feed the current disc-usage to a Linda-Tuplespace. The intervals of update are variable and to be configured. A CGI-script retrieves the information on request from the Tuplespace and convert it to HTML. The system administrators can check the status of the whole cluster at the first glance. The structure of 'DiscTool' is shown in Figure 11 gif.

Figure 11: Structure of DiscTool

The information in the Tuplespace is updated by the clients every 5-10 minutes. In the intervals between updates, the processes sleep in order to consume no CPU-time. We have chosen a 2-level interface for the output of disc-usage. The first level shows an overview over the cluster, every partition on the harddisc is represented by an icon. Figure 12 is a screenshot of this overview. If the administrator requires details about a specific partition, he clicks on the icon and further information is retrieved from the Tuplespace.

Figure 12: Screen-Shot of DiscTool-Overview

Figure 13: Screen-Shot of DiscTool - Detailed Information

Continuous Course Evaluation via W3

The second application we present in this paper is a transaction system, which allows continuous opinion polls. Course evaluations are undertaken at the Vienna University of Economics and Business Administration (WU-Wien) every year. This is a very time consuming process. Much paperwork is involved, because the whole evaluations are based on paper-forms on which the students have to evaluate their courses. These questionaires have to be entered in a spread-sheet. On this base, the evaluation can be done. The output is a brochure, containing all lectures and their evaluation. This is a very good information for new students to get an impression of course quality.

Since editions of this brochure are usually released with large delays (6 to 9 months late), we decided to support course-evaluation with a W3-based application. Requirements for this application are to provide configurable front-ends for the polls which are campus-wide available. Further, a continuous evaluation, based on the data entered should be provided to give both, lecturer and students the opportunity to discuss the course quality immediately at the end of the course.

Especially with course evaluation, the implementation problem is, that many students are evaluating the same course at the same time (e.g. after the course) and that each needs an exclusive access to the data-file. Since the data has to be saved in files, the read/write-access is only possible for one client. A correct implementation of this client must use lock-files and inter process communication to ensure exclusive access to the data-files. The second problem is, that a normal CGI-script has to read, evaluate and write all the data on every request.

Linda solves both problems. A Tuplespace is placed in between the evaluation-process and the input/output-process. The students fill out a questionaire in a HTML-form. The results of this questionaire are sent to the Tuplespace. Each questionaire is assigned a transaction number for identification. The CGI-script gets the last used id-number from the Tuplespace and increases it by one. Then it is stored into the Tuplespace again. After sending the data, the CGI-script returns a confirmation to the front-end. The user can now decide what to do next. The evaluation process retrieves the stored data from the Tuplespace and evaluates it. This is considerably faster, because the evaluation process has the evaluation data in the memory and therefore does not need to read the data-file. After calculating the results, they are put into the Tuplespace with the URL of a graph of the evaluation in gif-format, specially created for the course. If the user decides to view the evaluation of the course, the information is retrieved from the tuple-space and displayed. The user gets the newest updated version of the evaluation. The evaluation- and update-time depends on the number of simultaneous requests and the speed of the host. The structure of the application is very similar to the structure in Figure 8gif.


In this paper we presented the implementation of W3-based applications with Linda, a high level set of functions for process coordination and parallel processing which have been added to several programing languages. The inclusion of Linda provides both, a standardized interface to other systems and programming languages and the ability to overcome the limitations of conventional CGI-scripts. This is achieved by separation of input/output-processing and data-processing. Linda is responsible for the coordination and synchronization of the application, whereas the CGI-script is only responsible for input/output processing. Additionally, Linda allows interaction between distributed applications on different hosts connected with a TCP/IP-network.

Combining Linda with W3 allows new types of applications such as multi user interaction systems, cooperative games and stateful stateful server application to be used with a standard W3-front-end. All this can be established on the Input/Output-side with considerably small Perl-scripts. We showed two sample applications, in which the W3-front-end proved to be easy to implement and easy to use.

In further development of Perl Linda we intend to extend the current implementation with the feature of atomicity for multiple commands and usage of multiple workspaces with the possibility of replication. Future research in Linda-WWW applications is planned in experimental economics. We intend to implement market simulations including interaction of human competitors with adaptive agents which interact via a Tuplespace. W3 is a very good front-end for this task, because it does not limit you to text mode and provides a system-independent interface to the prospective users. Concerning Perl Linda we intend to add the feature of atomicity for multiple commands and replication and usage of multiple workspaces.


Bakken, D.E.; Schlichting, R.D.: `Supporting Fault-Tolerant Parallel Programming in Linda'' in `IEEE Transactions on Parallel and Distributed Systems'', Vol. 6, No. 3, March 1995

Callsen, C.J; Cheng, I.; Hagen, P.L.: `The AUC C++Linda System'' in `Linda-Like Systems and Their Implementation'', Technical Report 91-13, Edinburgh Parallel Computing Center, Edinburgh 1991

Carriero, N.; Gelernter, D.: `How to write Parallel Programs: A Guide to the Perplexed'' in "ACM Computing Surveys", Vol.21, No.3, September 1989

Carriero, N.; Freeman, E.; Gelernter, D.; Kaminsky, D.: `Adaptive Parallelism with Piranha'', Technical Report 954, Yale University Department of Computer Science, Feb. 1993,
See: http://www.yale.cs.edu/HTML/YALE/CS/Linda/papers/workshop.ps

The Common Gateway Interface,
See: http://hoohoo.ncsa.uiuc.edu/cgi/overview.html

"CGI Form Handling in Perl", Steven E. Brenner,
See: http://www.bio.cam.ac.uk/web/form.html

Ciancarini, P.: `Distributed Programming with Logic Tuple Spaces'', Technical Report UBLCS-93-7, Laboratory for Computer Science, University of Bologna, 1993

Comer, D.E.; Stevens, D.L.: "Internetworking With TCP/IP, Vol III: Client-Server Programming And Applications", Prentice Hall, Englewood Cliffs, New Jersey 1993

Gelernter, D.: `Generative Communication in Linda'' in `ACM Transactions on Programming Languages and Systems

Gray, J., Reuter A.: "Transaction Processing: Concepts and Techniques", Morgan Kaufmann Publishers, San Mateo 1993

Supporting Forms with CGI,
See: http://hoohoo.ncsa.uiuc.edu/cgi/forms.html

Hietler, G.: `The APL-Linda Client: A Technical Documentation'', Technical Report, Janko-Hansen (Eds.) No.14, `Institut für Informationswirtschaft, WU-Wien, Augasse 2-6, A-1090 Wien/Austria'', Vienna September/1995

The Hypertext Markup Language,
See: http://www.w3.org/hypertext/WWW/MarkUp/MarkUp.html

The Hypertext Transfer Protocol,
See: http://www.w3.org/hypertext/WWW/Protocols/HTTP/HTTP2.html

Klute R.: "Zweiter Gang", in "iX Multiuser Multitasking Magazin" 8/1994, p.140-146, Verlag Heinz Heisse GmbH & Co KG, Hannover 1994

Martin J., Loeben J.: "TCP/IP networking : architecture, administration and programming", Prentice Hall, Englewood Cliffs, 1994

Perrochon L., Fischer R.: "IDLE: Unified W3-Access to Interactive Information Servers" in "Proceedings of the Third International WWW Conference", Darmstadt 1995.
See: http://www.igd.fhg.de/www/www95/papers/58/www95.html

A C++-Class for processing the Output of HTML-Forms..
See: /pub/WWW/tools/ReadParseCxx.tar.gz

The Common Gateway Interface,
See: http://hoohoo.ncsa.uiuc.edu/cgi/primer.html

Schoenfeldinger, W.J.: `The Perl Linda Server: A Technical Documentation'' , Technical Report, Janko-Hansen (Eds.) No.12, "Institut für Informationswirtschaft, WU-Wien, Augasse 2-6, A-1090 Wien/Austria", Vienna July/1995

Siegel, E.H.; Cooper E.C.: `Implementing Distributed Linda in Standard ML'', Technical Report, CMU-CS-91-151, School of Computer Science, Carnegie Mellon University, Pittsburgh 1991

Wall, L.; Schwartz, R. L.: "Programming in Perl", O'Reilly & Associates, Cambridge/Mass 1990

Wilson, G.: `Improving the Performance of Generative Cummunication Systems by Using Application-Spezific Mapping Functions'' in `Linda-Like Systems and Their Implementation'', Technical Report 91-13, Edinburgh Parallel Computing Center, Edinburgh 1991