Figure 1: State information stored in pages
Werner J. Schoenfeldinger
Keywords: World Wide Web (W3), user interfaces, Linda, CGI programming, Perl
Using WWW (W3) as a frontend 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 frontend for multiuser, transaction processing applications and mass-information systems. However, two severe problems limit the applicability of W3 for this kind of systems:
In this paper, we suggest a uniform and general solution to the second problem by integrating the coordination language Linda [9] with the W3 frontend. Two simple applications are provided to illustrate the power of this approach.
This section provides a brief overview about W3-based frontends for user applications. Starting with a short definition of the Common Gateway Interface, we describe the main parts of CGI scripts and try to point out problems with the use of W3 as frontend 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 frontend. 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.
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]:
If the form has METHOD=`GET'' in its FORM tag, the CGI script will receive the encoded form input in the environment variable QUERY_STRING.
If the form has METHOD=`POST'' in its FORM tag, the CGI script will receive the encoded form input on STDIN. The server will not send an EOF at the end of the data. The number of characters which should be read from STDIN is stored in the environment variable CONTENT_LENGTH.
The data is passed in a CGI-specific format [15]. 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 range from simple "output-only" scripts to sophisticated programs. Generally, we can identify three major parts in CGI scripts:
In most languages encoding or 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]:
<A HREF="/CGI/myscript/this_var=15"> testlink</A>
In this case, data is passed in the PATH_INFO variable. In the example, this variable contains "/this_var=15".
<A HREF="/CGI/myscript?this_var=15"> testlink</A>
This method works in the same way as the GET method with an HTML form. The data is passed in the variable QUERY_STRING. Note that the transfer requires a specific format.
The programmer must decide how data is passed. If you use a method other 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:
Location: /path/to/some_doc.html
The reference will be interpreted by the server and the stated document will be browsed. This mechanism is used with ISMAP-structures.
Content-type: text/html
In this case the whole document is an output of the CGI script. The script has to give some hints to the server about the document's type. This is performed in stating type and subtype of the document. In our case, the type is HTML.
Under UNIX, the CGI program is invoked by the HTTP server under a specific user ID and group ID. 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.
As documented in [17], the HTTP server is a stateless server and, therefore, cannot keep any state information for running scripts. If applications require state information, the state has to be maintainted by the script. Two common ways to deal with this problem include:
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 multiuser 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 such situations it is possible that a client can crash, the state information can get lost, and a deadlock in the whole application can result. We find these problems in many types of applications: computer games, credit card validation and credit approval, computer based exams, etc., to name a few.
Figure 1: State information stored in pages
Using the file system of the HTTP server's host as a storage medium requires two things. First, the user ID, under which the HTTP server runs, must have access to an area in the file system. On UNIX systems, this could be /usr/tmp. Second, this storage method 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 overcome this limitation by sharing the relevant data amongst hosts on which it is needed. In such a solution, the data has to be placed in a directory, accessible by all participating hosts.
For building large multiuser transaction systems, W3 is an attractive frontend. Unfortunately, however, transaction processing is a major problem for W3-based applications. Today, transaction processing, process communication and synchronization, data locking, etc. are not supported by the existing CGI toolbox which is available for most HTTP servers. The application programmer must ensure that no conflicts and deadlocks can occur when several users invoke CGI scripts at the same time. Because the file system is the only shared media between the different CGI processes, stability for multiuser transactions can only be achieved through lock files and access delays.
In this section we describe Linda, a 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. The core 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. No empty fields can exist in tuples. How tuples are represented in the Tuplespace is highly dependent on the implementation. In the Perl Linda implementation, they are stored in encoded ASCII-text. Some tuple examples are shown below:
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 [3] are:
The function out() puts a tuple into the Tuplespace. The tuple can be retrieved by all other processes with the help of other Linda functions. With out(), you can only put data tuples into the Tuplespace. Out never blocks.
For retrieving tuples from the Tuplespace, we use the function in(). This function removes all tuples which match a given template from the Tuplespace and returns them. A template is a tuple with formal fields, to which actual values can be assigned during the matching process. However, no match exists in the Tuplespace in() blocks until at least one matching tuple appears in this space.
Read is quite similar to in(). The difference is that rd() does not remove the matching tuples from the Tuplespace.
Eval creates an active tuple, in fact a task-descriptor for which, in Perl Linda, the Linda server is responsible for computation. The active tuple may consist of ordinary elements and functions which need evaluation. The results are stored as a passive tuple in the Tuplespace. Because the command is highly language-dependent, it is not yet implemented in the Perl-Linda implementation. We will not need eval() for our examples.
To prevent deadlocks, Perl Linda has two additional commands. They are nonblocking versions of the rd() and in() commands which have been implemented in the many versions of Linda [3, 1]. They are called nbin() (nonblocking in) and nbrd() (nonblocking 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 1.
Table 1: Two Communicating Processes Under Linda
In step 1, the clients put the tuples (x,b,2) and (a,c,4) to the Tuplespace. Client 2 tries to retrieve all three-element tuples with b as the second element using in(). Because there are matching tuples, they are retrieved from the Tuplespace and handed to Client 2. In step 4 we have an example for the blocking mechanism of in(). Tuples matching the pattern of the in()statement given by Client 1 are not found in the Tuplespace; therefore Client 1 blocks. The tuple sent by Client 2 in step 5 matches the pending request from Client 1 and it is transfered to Client 1 in step 6. The following out() statement of Client 2 is not sent to Client 1 because it was matching the pattern. This comes because a blocking in() or rd() is satisfied with just one 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 process automatically until a matching tuple arrives in the Tuplespace.
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. Linda was implemented in Perl as described below:
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 multiuser computer games. In these applications, we have learned that the Linda coordination language is a very powerful tool to coordinate several clients, and that the resulting client programs are considerably smaller than programs using a classical approach [8]. Distributed Tuplespaces among several servers on different hosts have been already been developed [1, 7, 21, 23], but have not yet been implemented in Perl Linda.
The requirements for using the Perl Linda server are 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.
Because the Linda server handles only the incoming requests from clients, and then stores or retrieves tuples from the Tuplespace, the processing of the tuples and transactions are left to the clients. We have developed clients for the following 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. No further coordination is necessary due to thee intrinsic blocking mechanism of the in() and the rd() commands, which are 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.
Because 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 like this:
To illustrate using a sample Perl Linda, we show
a Linda client for distributed counting in Example 1.
.
Several Linda clients count a variable from 1
to 10000 simultanesouly. Only one client is able to increase the variable at a
time. The coordination is left to the clients. Although
this task is not useful in itself, it represents a very good example
for parallel programming and coordination.
Example 1: Count Client in Perl Linda
#!/usr/local/bin/perl # Invoking Perl
require "linda-cli.pl"; # Adding the Linda library
#
®ister_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
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]. Because Linda does not provide the full functionality needed for transaction management, we have to keep certain server and client restrictions in mind.
Bakken [1] 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 can provide atomicity for a series of out() operations. Although this solution is feasible for Perl Linda too, implementation is left to future work.
The second area of problems, when using Linda for transactions systems, is a failure on the server side. To prevent data loss due to a crash on the server side, we have to solve two problems:
A solution for both problems has already been implemented through replication and use of multiple Tuplespaces [1]. In Perl Linda, the application programmer must provide the application such a facility, and can do so via signal handling. The server side has a mechanism which dumps the contents of the Tuplespace to the local file system and recovers the Tuplespace from it after the restart [20].
The basic reason for supporting W3-based applications with Linda is that the transaction of input/output processing and data processing can be separate. With Linda, CGI scripts are only responsible for input/output processing. On the other hand, the responsibility for all data processing and transactions is shifted to background application processes, which communicate with the CGI scripts via a Linda Tuplespace (see Figure 4). This procedure 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. Linda also provides W3 with an interface which meets the Transaction Processing Standards [10], as described below:
In a CGI script without Linda, the browser is being blocked until the CGI script is terminated. The structure of such an application is shown in Figure 3.
Figure 3: CGI application without Linda
For many applications this structure is not sufficient for the following reasons:
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, to script has to convert the data into HTML format.
Figure 4 shows the typical structure of a W3 Linda application. The CGI script interacts between the frontend and the Tuplespace. The other clients which are connected to the Tuplespace can run on different hosts and, of course, in different languages.
Figure 4: W3 and Linda working together
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, more applications can the data sent to the Tuplespace. This processing could, for example, result in a parallel search in several databases. The structure of such an application is shown in Figure 5. In Figures 4 and 5, for matters of clarity, the interactions are only shown for one process; however, this application structure works for multiple requests as well. If the processing of a task is very time consuming, more worker clients can be added to the Tuplespace waiting for tasks.
Figure 5: CGI application with Linda, waiting for task completion
By using Linda as an interconnector between frontend and application, we can develop a flexible, termination-independent structure, as shown in Figure 6.
The application simply checks the Tuplespace for requests. If a request is found in the Tuplespace, the request 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 then check if the results have arrived. This check can be completed either by automatically reloading the page or by a simple manual query.
Figure 6: Linda and W3, frontend is independent from application
In this section, we show how the interaction between Linda and W3 is implemented. Our code examples will be in Perl because it is often used for programming CGI scripts. Another reason for using Perl is that the interaction between the frontend and the Tuplespace is not time critical. Therefore, for this class of applications, Perl represents a flexible and sufficient solution.
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.
In Example 2, we show a very simple interaction between a form and the Tuplespace. No data processing is done; only the data transfer is implemented.
Example 2: Data Transfer from Form to Tuplespace
#!/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
®ister_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"
From this example we can see that very little code is needed to implement such a communication. This benefit is, to a great extent, due to the functionality embedded in the "required" libraries.
Example 3 deals with the data transfer in the other direction. Let us consider, as an example, a printer accounting system in which the spooler stores the information about the printed pages in a Tuplespace. The format for this is:
(PACC,<userid>,<number_of_pages_today>,<number_of_pages_total>) 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 for the user data in the Tuplespace. The first item, "PACC," is only necessary if the Tuplespace is used by several applications. The second component is the printer accounting statistic shown in Example 3.
Example 3: Source of Printer Highscore
#!/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]
#
®ister_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"; #
The examples show that one can easily separate the acquisition of information from the actual input/output processing. Furthermore, updating information does not depend on user requests. However, a user-dependent update of information can be implemented by the application structure shown in Figure 5.
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 hard disks in a cluster, independent of his current working system. The second application, LVA-Express, is 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 now have a cluster of 23 UNIX workstations. Software and applications are distributed amongst the hard disks of these computers. The motivation for this application is that disk space is a scarce resource. Due to automatic processes (ftp mirrors, system logs, mail, backups), disk usage frequently approaches 100%. In this case, users on the network may not be able to save their work, and documents cannot be printed or received. Immediate intervention of a system administrator is required.
The current solution is that the system administrator tries to predict disk shortages in order to take counter measures. Because the task of manually checking 17 systems can be a very time consuming job, we decided to build a W3-based application.
To check the disk usage on a system, we use the UNIX commands df and bdf, 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] implies access rights for the user nobody, which runs the HTTP server. For security reasons, this situation is unacceptable.
Our solution was to use Linda to overcome this problem. Tiny background scripts, running on every workstation in the background, should feed the current disk 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 converts it to HTML. The system administrators can check the status of the whole cluster at first glance. The structure of DiscTool is shown in Figure 7.
Figure 7: Structure of DiscTool
The information in the Tuplespace is updated by the clients every five to ten minutes. In the intervals between updates, the processes sleep in order to conserve CPU time. We have chosen a two-level interface for the output of disk usage. The first level shows an overview over the cluster, with each partition on the hard disk being represented by an icon. Figure 8 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 (see Figure 9).
Figure 8: Screen shot of DiscTool overview
Figure 9: Screen shot of DiscTool: detailed information
The second application we present in this paper is a transaction system, which allows continuous opinion polls. Course evaluations are completed at the Vienna University of Economics and Business Administration (WU-Wien) every year. This process is very time consuming. Much paperwork is involved; the evaluations are based on paper forms which the students complete to evaluate their courses. These questionnaires are entered in a spreadsheet, the output of which is a brochure, containing each lecturer and the corresponding evaluation. This output provides valuable information for new students seeking impressions of course quality.
Since editions of this brochure are usually released with large delays (six to nine months late), we decided to support course evaluation with a W3-based application. Requirements for this application are to provide configurable frontends for the polls which are available throughout the campus. Furthermore, a continuous evaluation, based on data entered, should be provided to give both the lecturers and students the opportunity to discuss course quality immediately at the end of each course.
With course evaluations, the implementation problem is that many students are evaluating the same course at the same time (e.g., after the course), and that each student needs 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 at a time. 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 questionnaire in an HTML form. The results of this questionnaire are sent to the Tuplespace, and each questionnaire 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 the number is stored in the Tuplespace again. After sending the data, the CGI script returns a confirmation to the frontend. The user can now decide what to do next. The evaluation process retrieves the stored data from the Tuplespace and evaluates it. This process is considerably faster, because the process keeps the evaluation data in memory and, therefore, does not need to read the data file. After the results are calculated, they are put into the Tuplespace, along with the URL of graph evaluation in gif format, which was specially created for the course. If the user decides to view the evaluation of the course, the information is retrieved from the Tuplespace 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 shown in Figure 6.
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. These aspects are achieved by separating 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 multiuser interaction systems, cooperative games, and stateful server applications is to be used with a standard W3 frontend. These applications can be established on the input/output side with small Perl scripts. We showed two sample applications in which the W3 frontend proved to be easy to implement and easy to use.
In future 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 frontend for this task, because it does not limit you to text mode and provides a system-independent interface to the prospective users.
1. Bakken, D.E., and Schlichting, R.D. "Supporting Fault-Tolerant Parallel Programming in Linda" in IEEE Transactions on Parallel and Distributed Systems, Vol. 6, No. 3, March 1995.
2. Callsen, C.J., Cheng, I., and 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.
3. Carriero, N., and Gelernter, D. "How to write Parallel Programs: A Guide to the Perplexed" in ACM Computing Surveys, Vol.21, No.3, September 1989.
4. Carriero, N., Freeman, E., Gelernter, D., and
Kaminsky, D. Adaptive Parallelism with Piranha, Technical
Report 954, Yale University Department of Computer Science, Feb.
1993,
http://www.yale.cs.edu/HTML/YALE/CS/Linda/papers/workshop.ps
5. "The Common Gateway Interface,"
http://hoohoo.ncsa.uiuc.edu/cgi/overview.html
6. "CGI Form Handling in Perl," Steven
E. Brenner,
http://www.bio.cam.ac.uk/web/form.html
7. Ciancarini, P. "Distributed Programming with Logic Tuple Spaces," Technical Report UBLCS-93-7, Laboratory for Computer Science, University of Bologna, 1993.
8. Comer, D.E., and Stevens, D.L. Internetworking With TCP/IP, Vol III: Client-Server Programming And Applications, Prentice Hall, Englewood Cliffs, New Jersey 1993.
9. Gelernter, D. "Generative Communication in Linda" in ACM Transactions on Programming Languages and Systems
10. Gray, J., and Reuter A. Transaction Processing: Concepts and Techniques, Morgan Kaufmann Publishers, San Mateo 1993.
11. "Supporting Forms with CGI,"
http://hoohoo.ncsa.uiuc.edu/cgi/forms.html
12. 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.
13. "The Hypertext Markup Language,"
http://www.w3.org/hypertext/WWW/MarkUp/MarkUp.html
14. "The Hypertext Transfer Protocol,"
http://www.w3.org/hypertext/WWW/Protocols/HTTP/HTTP2.html
15. Klute R. "Zweiter Gang," in iX Multiuser Multitasking Magazin 8/1994, p.140-146, Verlag Heinz Heisse GmbH & Co KG, Hannover 1994.
16. Martin J., and Loeben J. TCP/IP networking : architecture, administration and programming, Prentice Hall, Englewood Cliffs, 1994.
17. Perrochon L., and Fischer R. "IDLE: Unified
W3 Access to Interactive Information Servers" in Proceedings
of the Third International WWW Conference, Darmstadt 1995.
http://www.igd.fhg.de/www/www95/papers/58/www95.html
18. "A C++-Class for processing the Output of
HTML-Forms."
/pub/WWW/tools/ReadParseCxx.tar.gz
19. "The Common Gateway Interface,"
http://hoohoo.ncsa.uiuc.edu/cgi/primer.html
20. 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.
21. Siegel, E.H., and Cooper E.C. Implementing Distributed Linda in Standard ML, Technical Report, CMU-CS-91-151, School of Computer Science, Carnegie Mellon University, Pittsburgh 1991.
22. Wall, L., and Schwartz, R. L. Programming in Perl, O'Reilly & Associates, Cambridge/Mass 1990.
23. 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.
Werner J.Schoenfeldinger
Department for Applied Computer Science
Vienna University of Economics and Businness Administration
schoenf@aia.wu-wien.ac.at