WASD Hypertext Services - Scripting Environment

A Run-Time Environment (RTE) is a persistant scripting environment with similar objectives to CGIplus ... reducing script response time, increasing server throughput and reducing system impact. In fact the RTE environment is implemented using CGIplus! There is very little difference in the behaviour of CGIplus scripts and RTEs. Both are activated by the server, process multiple requests (reading the request CGI environment from a data stream supplied by the server), persist between requests in a quiescent state, and may be removed by the server if idle for a specified period or when it wishes to use the process for some other purpose. Like CGIplus an RTE must be purpose-written for the environment! What is the difference then?

With CGIplus the script itself persists between uses, retaining all of it's state. With an RTE the script does not persist or retain state, only the RTE itself.

A RTE is intended as an environment in which a script source is interpreted or otherwise processed, that is for scripting engines, although it is not limited to that. The essential difference between an RTE and a CGIplus script is this script source. In CGIplus the SCRIPT_NAME and SCRIPT_FILENAME CGI variables reflect the script itself, and remain constant for each activation of the script, with PATH_INFO and PATH_TRANSLATED providing the additional "location" information for the script processing. With an RTE the SCRIPT_NAME and SCRIPT_FILENAME can vary with each activation. This allows the RTE to process multiple, successive different (or the same) scripts, each with it's own PATH_INFO and PATH_TRANSLATED. Hence, it is not unreasonable to consider the two environments to be the same, with a slight difference in the mapping of resources passed to them.

This might be best illustrated with examples.

CGIplus Example

Consider the mapping rule

  exec+ /cgiplus-bin/* /cgi-bin/*

  /cgiplus-bin/xyz/the/path/information?and=a&query=string

If the script was an executable it would be activated as

  CGI-BIN:[000000]XYZ.EXE

  /cgiplus-bin/xyz
  CGI-BIN:[000000]XYZ.EXE

  /the/path/information
  THE:[PATH]INFORMATION
  and=a&query=string

By contrast with a request to activate an RTE the following mapping rule

  exec+ /xyz-bin/* (CGI-BIN:[000000]XYZ.EXE)/ht_root/src/xyz/*

  /xyz-bin/an_example/the/path/information?and=a&query=string

  CGI-BIN:[000000]XYZ.EXE

  /xyz-bin/an_example.xyz
  HT_ROOT:[SRC.XYZ]AN_EXAMPLE.XYZ

  /the/path/information
  THE:[PATH]INFORMATION
  and=a&query=string

As can be seen the script information is constant for each request to a CGIplus script, while with RTE the script information could vary with each request (although of course it would be the same if the same script is requested). In the case of CGIplus the process what? request information is provided only by path information, however with RTE both script and path information are used.

4.1 - RTE Programming

The RTE interface is still CGI, with all the usual environment variables and input/output streams available, just in a CGIplus environment! Hence when coding a Run-Time Environment the same considerations involved in CGIplus programming apply (3 - CGIplus).

In particular it is important a RTE should explicitly close files, free allocated memory, etc., after processing a request (of course it cannot rely on image run-down to clean-up after itself). It is particularly important that all traces of each script's processing are removed after it concludes. This does not mean for example that databases need to be completely closed, etc., which might defeat the purpose of using a persistant environment, just that great care must be exercised by the programmer to prevent one script interfering with another!

An example RTE, HT_ROOT:[SRC.CGIPLUS]RTE_EXAMPLE.C provides the basics of the environment.

A source code collection of C language functions useful for processing the more vexing aspects of CGI/CGIplus/RTE programming (1.10 - Scripting Function Library). The example RTE implementation uses this library.

4.2 - Server Configuration

The following configuration information uses the supplied Perl RTE as the example. Note that RTE scripting engines must always be mapped using the EXEC+ rules. The SCRIPT+ rule does not apply.

The following rule in HTTPD$MAP maps the /pl-bin/ location to where the site wishes to locate it's CGI Perl scripts (not necessarily the same as in the example).

  exec+ /pl-bin/* (CGI-BIN:[000000]PERLRTE.EXE)/ht_root/src/perl/*

With this rule Perl scripts may be accessed using

  http://host.name.domain/pl-bin/an_example

A DCL procedure can be specified in place of an executable. Merely prefix the specification with a "@".

This HTTPD$CONFIG rule ensures Perl scripts could be activated via the Perl RTE even if the HTTPD$MAP rule did not exist (1.6 - Script Run-Time).

  [DclScriptRunTime]
  .PL  (CGI-BIN:[000000]PERLRTE.EXE)

NOTE

---

The server makes no check of the RTE executable (or procedure) before attempting to activate it using DCL for processing the script. If it does not exist or is not accessable due to incorrent file protections the DCL of the scripting process will report the problem.

---

It does by default however, check that the file used as the script source exists as with other scripting environments. If it does not this is reported as a "script not found". For RTEs that wish to report on this themselves, or that possibly construct their own script specification via some internal processing, this server behaviour may be suppressed for the script activation path using the HTTPD$MAP path SETting "script=nofind" as in the following example.

  set /xyz-bin/* script=nofind
  exec+ /xyz-bin/* (CGI-BIN:[000000]XYZ.EXE)/ht_root/src/xyz/*