| [ directory ] |
|
1.1 A Brief History of the WebA Web transaction involves two participants: the browser and the server. As originally conceived, the browser was supposed to be a very simple, lightweight program that would allow users to navigate through data. This data could consist of plain text, HTML, images, and so on, and the browser would render all the data in a way that humans could understand and interact with. Data could be interconnected, and the browser would render references between documents as an image or text that could be clicked or otherwise selected. Over time, regrettably, rapid development, the race to add new features, and poor adherence to standards have caused browsers to lose the simplicity for which they once strived. This has resulted in a situation best summarized by Internet legend James "Kibo" Parry's description of browsers as "fragile assemblies of bugs, held together with Hello Kitty stickers." The server is an equally complex program. The server is responsible for finding the data requested by the browser, packaging the data for transmission, and sending it back to the browser. In the simplest kind of Web transaction, the browser asks for a single document from the server, and the server retrieves this data and sends it back, at which point the browser renders it in an appropriate way for the user. This whole process is shown in Figure 1.1. Figure 1.1. The relationship between browser and server.
This basic activity has many variations. The data being requested by the browser may come from a user typing a URL (universal resource locater) directly, may be in response to the user's clicking a link, or may be automatic, such as an image contained within a page. In each case, the server will receive a properly formatted request for the data, no matter how the request is generated on the client. How the server fulfills this request also has many variations. In the simplest model, the response may come from a file. Often, there is a simple relationship between URLs and such files. For example, the URL http://somesite.net/lyrics/This_Ascension/forever_shaken.txt might come from a file called C:\Webfiles\This_Ascension\forever_shaken.txt on the computer called somesite.net. However, just as the server does not care how the request is generated, the client does not care how the response is constructed. Storing data in a file is perfectly adequate for information that never changes, such as the lyrics to a song, or that doesn't change very often, such as a band's tour schedule. When a new date is added to such a schedule, someone can simply edit the file by using a text editor, such as emacs, vi, or notepad, or a full HTML editor, such as Dreamweaver. However, the file-based model does not work for information that changes very rapidly or that requires input from the user. Following are a few of the ways in which a site might need to take input from a user.
What all these situations have in common is that the content is now dynamic; it needs to change based on time, user input or preferences, or any of hundreds of other attributes. |
| [ directory ] |
|