In fact, one could make the argument that moving toward a web server architecture
is akin to stepping backward in time—to the time of centralized mainframes and
dumb terminals. Some would include the emerging cloud computing model in this
analysis, arguably in part a throwback to older computing models. Whichever way
we step, offloading and distributing processing to client machines at least partially
avoids this processing bottleneck.Other Approaches
So what’s the best way to build applications for the Internet—as client-side programs
that talk to the Net or as server-side programs that live and breathe on the Net? Natu-
rally, there is no one answer to that question, since it depends upon each application’s
unique constraints. Moreover, there are more possible answers to it than have been
disclosed so far. Although the client and server programming models do imply trade-
offs, many of the common web and CGI drawbacks already have common proposed
solutions. For example:
Client-side solutions
Client- and server-side programs can be mixed in many ways. For instance, applet
programs live on a server but are downloaded to and run as client-side programs
with access to rich GUI libraries.
Other technologies, such as embedding JavaScript or Python directly in HTML
code, also support client-side execution and richer GUI possibilities. Such scripts
live in HTML on the server but run on the client when downloaded and access
browser components through an exposed object model to customize pages.
The Dynamic HTML (DHTML) extensions provide yet another client-side script-
ing option for changing web pages after they have been constructed. And the newly
emerging AJAX model offers additional ways to add interactivity and responsive-
ness to web pages, and is at the heart of the RIA model noted ahead. All of these
client-side technologies add extra complexities all their own, but they ease some
of the limitations imposed by straight HTML.
State retention solutions
We discussed general state retention options in detail in the prior chapter, and we
will study full-scale database systems for Python in Chapter 17. Some web appli-
cation servers (e.g., Zope) naturally support state retention between pages by pro-
viding concurrently accessible object databases. Some of these systems have an
explicit underlying database component (e.g., Oracle and MySQL); others may use
flat files or Python persistent shelves with appropriate locking. In addition, object
relational mappers (ORMs) such as SQLObject allow relational databases to be
processed as Python classes.
Scripts can also pass state information around in hidden form fields and generated
URL parameters, as done in PyMailCGI, or they can store it on the client machine
itself using the standard cookie protocol. As we learned in Chapter 15, cookies are
1296 | Chapter 16: The PyMailCGI Server