CGI – an outdated concept?
This question quickly pops into one's mind when one notices how dynamic web
content is generated nowadays: Here AJAX, there PHP, and jQuery somewhere else
- as well as a bunch of other approaches to compile and display content the
moment a page is requested. Some of them run on the server's side (see PHP)
whereas others rely on the capabilities of a browser (like AJAX or jQuery).
Here PHP displays some similarities to CGI, except that it is a hybrid of
regular HTML and script areas with the latter being recognized as such by the
web server and executed accordingly. The result is output together with the
rest of the HTML at exactly the spot the script has been recorded at.
Things run a bit differently with CGI, though: When a request is made to the
web server that points to a CGI script or program it is invoked by the web
server. Any potential data to be transferred are passed as en environment
variable in case of URL parameters, or in case POST data has to be transferred,
they wind up on the standard input of the CGI program which in turn processes
the passed data and outputs the result on its standard output. The data is in
turn taken by the web server and passed to the caller.
The web server is thereby relieved from its load so that it can exclusively
deal with delivering any requested data – any necessary evaluations take place
in a completely independent process.
But why CGI instead of PHP in the first place?
In contrast to CGI there's a significant catch on PHP: You are limited to a
specific scripting language whereas this limitation doesn't exist for CGI. In
the latter case you may use any old program that accepts data on its standard
input and returns its results via standard output providing it conforms to the
CGI interface or is capable of adapting itself to this condition. This allows
for invoking shell scripts, scripts in an arbitrary scripting language (Perl,
Python, Tcl, etc.) or even full-fledged programs. You have virtually all
options availabble in this case.
You even ton't have any limitations as to what you may return to the caller:
You may even tell him what kind of data you are returning and how!
How Perl comes into play
Perl's main characteristic is an extraordinary flexibility as far as
programming is concerned, which enables one to do virtually anything with it.
You may assign virtually all types of data without having to put up with its
structure (one must only differentiate betrween individual data – that is,
scalars, arrays, and hashes), the rest is done by Perl. And even if you have to
transform data from one form to another, you don't have to deal with that,
either, because Perl performs this transformation implicitly.
You are even able to modularize your scripts by moving functions that you
intend to use in a number of scripts to another file which is simply included
into your scripts. You avoid writing down the exact same piece of code at
different locations this way, thereby greatly simplifying any maintenance of
your code. If problems arise, you merely have to do modifications in one spot
only; the changes are applied at all spots you have included the affected
module at.
On top of that the programming style of Perl which is loosely based on the one
known from C makes your work easier as well and gives you more freedom at the
same time. This additionally simplifies your work, and instead of having to put
up with the internal structure of any data – in conjunction with any necessary
transformations – you may use it virtually any way you want.