Datasheet

Chapter 1: Web 2.0, Python, and Frameworks
5
the user’s experience of the application are tightly bound to the desktop, operating in general ignorance
of the larger networked world. When you think like an RCP end user, you often feel trapped by your
tools in the sense that if you lose the use of them, or if you lose your disk drive, you also lose your data
in a most profound way. For example, it will be hard to read your next great novel written in Enormicorp
PerfectWord if you don’t have Enormicorp PerfectWord.
One effect of the isolation of both the user and the application is that designers and developers of tradi-
tional (RCP) applications never considered it desirable to enable the easy sharing of content created by a
specific proprietary tool, except through arrangements like OLE or OpenDoc, which open up data shar-
ing on the operating system or on proprietary tools made by the same vendor. Additionally, they never
considered building significant community or social aspects into traditional software.
As discussed in the “Design Patterns for Web 2.0” sidebar later in the chapter, community aspects such
as user-created content, tagging, and commentary (common in Web 2.0 applications such as YouTube
and Wikipedia) would not have made sense in the era of one user executing one application on one com-
puter. User isolation was a condition of life — an application and the content the end user produced
existed on a solitary plane.
Sharing and dissemination of data was done by ad hoc means — for example, by attaching it to e-mail.
The intended recipient could share in the data only if they bought and supported the correct version of
the proprietary tool. This was true during the first couple of decades of modern computing. The gap
between the end users’ need to create, publish, and share their creations and the ability of pre-Web–era
software design to deliver even a modicum of capability in that regard was filled by what was called
desktop publishing or DTP . DTP was King: the big important designs and design ideas were all about put-
ting words, numbers, and static images onto something that looks like a page, and then printing these
pages for sharing. Python was an early response to the needs of system administrators and scientific
programmers.
And Then the Web (1.0) Happened
Eventually, people began to wonder why they needed to produce paper at all, and thus when the World
Wide Web (the Web) sprang into existence, DTP morphed almost overnight into Web publishing or WP.
Almost overnight, WP became the new King, efficiently producing HTML to drive applications and
represent words, numbers, and multiple media types such as still and moving images. When the Web
(1.0) came along, agile languages such as Python began to make inroads into areas very unlike the origi-
nal class of applications written mostly to enable a higher level of scripting. With the emergence of
Twisted Python as a networked-applications engine some years ago, a mimetic light bulb lit. People
began to think in terms of frameworks , and the notion of code that writes code began to circulate. Python,
Perl, and PHP developers in particular began to get a sense of empowerment, while puzzling out the
reason for all the manufactured buzz over expensive tools being developed by the same proprietary ven-
dors who dominated the RCP and DTP era. Wasn’t everything really just an elaboration of a snippet of
code that could write a page in response to a URL invocation of a
cgi-bin script, such as the Python
snippet in Listing 1-1 shows?