GoServe: Why not CGI?

Why not CGI?

Many Web servers support a protocol known as the Common Gateway Interface (CGI) for attaching and supporting scripts. GoServe does not yet support this interface directly due to a number of difficulties with the design, of which the most significant (in no particular order) are:

The primary means of communicating information to scripts is by the use of environment variables. These all have to be set before the script is called, and as the number of these grow the overhead approaches or exceeds the cost of interpreting the script (GoServe has dozens of state variables available to scripts).
For GoServe, Rexx variables could be set on startup -- but a clearer and more efficient way of retrieving information is to use specialized function calls (such as GoServe's REQFIELD) or general commands (such as GoServe's EXTRACT, READ, and CONTROL). With these mechanisms, data are moved only when required.
Environment variables are a per-process resource in OS/2; GoServe's scripts run on a per-thread basis (the script runs on the same thread that handles the incoming connection, with no process overhead or resource cleanup required).
The piping of the incoming data to the script would often mean that data is read even when unused, hence increasing the load on the server (and, in some cases, on the network and client browser).
For some servers, the output sent to the client is dependent on the name of the script (for example, scripts whose name begins with "nph-" may have their output treated differently from other scripts). This means that arbitrary script names cannot be supported.
Server directives (commands sent to the server) are sent using the same namespace (header lines) as the header information being sent to the client. Separating this information, as in GoServe, leads to a more reliable and extensible protocol.
CGI binary executables are loaded from .EXEs rather than as functions in a DLL (which would be at least twenty times faster).
CGI does not define a channel between the script and the server while the script is running. Hence, dynamic information (such as connections and load) known to the server cannot be made available to the script during processing.
Standard output is used as a data channel to the server; this means that the only data channel to the user (Webspinner) is standard error, which is inappropriate for informative or status information, often used while developing scripts. It also means that data is processed more often than needed.

For these reasons, it seemed unlikely that CGI scripts could be supported directly (that is, without changes being required) and with reasonable efficiency by GoServe. GoServe's filters provide equivalent function, and the processing logic will be essentially unchanged, so ports of the algorithms required are easy.

If necessary (for example, to use an existing CGI script), the CGI interface can be simulated by a GoServe filter. Porting the script will, however, give much better response times in many cases.

[ previous section | GoServe | next section ]