The Web Versus the Desktop
Of course, these systems’ specific functionality isn’t exactly the same—PyMailCGI is
roughly a functional subset of PyMailGUI—but they are close enough to capture com-
mon trade-offs. On a basic level, both of these systems use the Python POP and SMTP
modules to fetch and send email through sockets. The implementation alternatives they
represent, though, have some critical ramifications that you should consider when
evaluating the prospect of delivering systems on the Web:
Performance costs
Networks are slower than CPUs. As implemented, PyMailCGI isn’t nearly as fast
or as complete as PyMailGUI. In PyMailCGI, every time the user clicks a Submit
button, the request goes across the network (it’s routed to another program on the
same machine for “localhost,” but this setup is for testing, not deployment). More
specifically, every user request incurs a network transfer overhead, every callback
handler may take the form of a newly spawned process or thread on most servers,
parameters come in as text strings that must be parsed out, and the lack of state
information on the server between pages means that either mail needs to be
reloaded often or state retention options must be employed which are slower and
more complex than shared process memory.
In contrast, user clicks in PyMailGUI trigger in-process function calls rather than
network traffic and program executions, and state is easily saved as Python in-
process variables. Even with an ultra-fast Internet connection, a server-side CGI
system is slower than a client-side program. To be fair, some tkinter operations are
sent to the underlying Tcl library as strings, too, which must be parsed. This may
change in time, but the contrast here is with CGI scripts versus GUI libraries in
general. Function calls will probably always beat network transfers.
Some of these bottlenecks may be designed away at the cost of extra program
complexity. For instance, some web servers use threads and process pools to min-
imize process creation for CGI scripts. Moreover, as we’ve seen, some state infor-
mation can be manually passed along from page to page in hidden form fields,
generated URL parameters, and client-side cookies, and state can be saved between
pages in a concurrently accessible database to minimize mail reloads. But there’s
no getting past the fact that routing events and data over a network to scripts is
slower than calling a Python function directly. Not every application must care,
but some do.
Complexity costs
HTML isn’t pretty. Because PyMailCGI must generate HTML to interact with the
user in a web browser, it is also more complex (or at least, less readable) than
PyMailGUI. In some sense, CGI scripts embed HTML code in Python; templating
systems such as PSP often take the opposite approach. Either way, because the end
result of this is a mixture of two very different languages, creating an interface with
Web Scripting Trade-Offs| 1293