HTML in a CGI script can be much less straightforward than making calls to a
GUI API such as tkinter.
Witness, for example, all the care we’ve taken to escape HTML and URLs in this
chapter’s examples; such constraints are grounded in the nature of HTML. Fur-
thermore, changing the system to retain loaded-mail list state in a database between
pages would introduce further complexities to the CGI-based solution (and, most
likely, yet another language such as SQL, even if it only appears near the bottom
of the software stack). And secure HTTP would eliminate the manual encryption
complexity but would introduce new server configuration complexity.Functionality limitations
HTML can say only so much. HTML is a portable way to specify simple pages and
forms, but it is poor to useless when it comes to describing more complex user
interfaces. Because CGI scripts create user interfaces by writing HTML back to a
browser, they are highly limited in terms of user-interface constructs. For example,
consider implementing an image-processing and animation program as CGI
scripts: HTML doesn’t easily apply once we leave the domain of fill-out forms and
simple interactions.
It is possible to generate graphics in CGI scripts. They may be created and stored
in temporary files on the server, with per-session filenames referenced in image tags
in the generated HTML reply. For browsers that support the notion, graphic images
may also be in-lined in HTML image tags, encoded in Base64 format or similar.
Either technique is substantially more complex than using an image in the tkinter
GUI library, though. Moreover, responsive animation and drawing applications
are beyond the scope of a protocol such as CGI, which requires a network trans-
action per interaction. The interactive drawing and animation scripts we wrote at
the end of Chapter 9, for example, could not be implemented as normal server-
side scripts.
This is precisely the limitation that Java applets were designed to address—
programs that are stored on a server but are pulled down to run on a client on
demand and are given access to a full-featured GUI API for creating richer user
interfaces. Nevertheless, strictly server-side programs are inherently limited by the
constraints of HTML.
Beyond HTML’s limitations, client-side programs such as PyMailGUI also have
access to tools such as multithreading which are difficult to emulate in a CGI-based
application (threads spawned by a CGI script cannot outlive the CGI script itself,
or augment its reply once sent). Persistent process models for web applications
such as FastCGI may provide options here, but the picture is not as clear-cut as on
the client.
Although web developers make noble efforts at emulating client-side capabilities—
see the discussion of RIAs and HTML 5 ahead—such efforts add additional com-
plexity, can stretch the server-side programming model nearly to its breaking point,
and account for much of the plethora of divergent web techniques.
1294 | Chapter 16: The PyMailCGI Server