But before we all jump on the collective Internet bandwagon and utterly abandon tra-
ditional desktop APIs such as tkinter, a few words of larger context may be in order in
conclusion.
PyMailCGI Versus PyMailGUI
Besides illustrating larger CGI applications in general, the PyMailGUI and PyMailCGI
examples were chosen for this book on purpose to underscore some of the trade-offs
you run into when building applications to run on the Web. PyMailGUI and PyMailCGI
do roughly the same things but are radically different in implementation:
PyMailGUI
This is a traditional “desktop” user-interface program: it runs entirely on the local
machine, calls out to an in-process GUI API library to implement interfaces, and
talks to the Internet through sockets only when it has to (e.g., to load or send email
on demand). User requests are routed immediately to callback handler method
functions running locally and in-process, with shared variables and memory that
automatically retain state between requests. As mentioned, because its memory is
retained between events, PyMailGUI can cache messages in memory—it loads
email headers and selected mails only once, fetches only newly arrived message
headers on future loads, and has enough information to perform general inbox
synchronization checks. On deletions, PyMailGUI can simply refresh its memory
cache of loaded headers without having to reload from the server. Moreover, be-
cause PyMailGUI runs as a single process on the local machine, it can leverage tools
such as multithreading to allow mail transfers to overlap in time (you can send
while a load is in progress), and it can more easily support extra functionality such
as local mail file saves and opens.
PyMailCGI
Like all CGI systems, PyMailCGI consists of scripts that reside and run on a server
machine and generate HTML to interact with a user’s web browser on the client
machine. It runs only in the context of a web browser or other HTML-aware client,
and it handles user requests by running CGI scripts on the web server. Without
manually managed state retention techniques such as a server-side database sys-
tem, there is no equivalent to the persistent memory of PyMailGUI—each request
handler runs autonomously, with no memory except that which is explicitly passed
along by prior states as hidden form fields, URL query parameters, and so on.
Because of that, PyMailCGI currently must reload all email headers whenever it
needs to display the selection list, naively reloads messages already fetched earlier
in the session, and cannot perform general inbox synchronization tests. This can
be improved by more advanced state-retention schemes such as cookies and server-
side databases, but none is as straightforward as the persistent in-process memory
of PyMailGUI.
1292 | Chapter 16: The PyMailCGI Server