also complicate the web development story even further, and add yet additional
languages to the mix. Though this can vary, the net result is often something of a
Web-hosted Tower of Babel, whose development might require simultaneously
programming in Python, HTML, SQL, JavaScript, a server-side templating lan-
guage, an object-relational mapping API, and more, and even nested and embed-
ded combinations of these. The resulting software stack can be more complex than
Python and a GUI toolkit.
Moreover, RIAs today inherit the inherent speed degradation of network-based
systems in general; although AJAX can add interactivity to web pages, it still implies
network access instead of in-process function calls. Ironically, much like desktop
applications, RIAs may also still require installation of a browser plug-in on the
client to be used at all. The emerging HTML 5 standard may address the plug-in
constraint and ease the complexity somewhat, but it brings along with it a grab
bag of new complexities all its own which we won’t describe here.Clearly, Internet technology does come with some compromises, and it is still evolving
rapidly. It is nevertheless an appropriate delivery context for many, though not all,
applications. As with every design choice, you must be the judge. While delivering
systems on the Web may have some costs in terms of performance, functionality, and
complexity, it is likely that the significance of those overheads will continue to diminish
with time. See the start of Chapter 12 for more on some systems that promise such
change, and watch the Web for the ever-changing Internet story to unfold.
Suggested Reading: The PyErrata System
Now that I’ve told you all the reasons you might not want to design systems for the
Web, I’m going to completely contradict myself and refer you to a system that almost
requires a web-based implementation. The second edition of this book included a
chapter that presented the PyErrata website—a Python program that lets arbitrary
people on arbitrary machines submit book comments and bug reports (usually called
errata) over the Web, using just a web browser. Such a system must store information
on a server, so it can be read by arbitrary clients.
Because of space concerns, that chapter was cut in this book’s third edition. However,
we’re making its original content available as optional, supplemental reading. You can
find this example’s code, as well as the original chapter’s file in the directory PP4E
\Internet\Web\PyErrata of the book examples distribution tree (see the Preface for more
on the examples distribution).
PyErrata is in some ways simpler than the PyMailCGI case study presented in this
chapter. From a user’s perspective, PyErrata is more hierarchical than linear: user in-
teractions are shorter and spawn fewer pages. There is also little state retention in the
web pages themselves in PyErrata—URL parameters pass state in only one isolated
case, and no hidden form fields are generated.
On the other hand, PyErrata introduces an entirely new dimension: persistent data
storage. State (error and comment reports) is stored permanently by this system on the1298 | Chapter 16: The PyMailCGI Server