The Be-All End-All of the Internet

One could say that's the lesser-known name for the World Wide Web. To many people even, the Web and the Internet are synonymous, which makes sense since they arrived in the public consciousness simultaneously. For anyone using computers and computer networks between 1992 and 1994, they're likely to remember the transition from modems and bulletin board systems (BBS) to the Internet. Certainly, the Internet had been around for quite a while, but the use of it was frankly not that appealing until one was exposed to their first World Wide Web client.

For me, sure, I was pretty familiar with Telnet and various UNIX email clients that worked completely in text mode. (Truly hardcore geeks will attest that is the real Internet, not all this Web noise. I am certainly not that hardcore of a geek.) There was also the Gopher service, which could fetch purely textual documents, which had -- interestingly enough -- the ability to hyper-link between pages. Yeah, you could say it was the Web without graphics and glitz, but the rendering power of an eighty-by-twenty-five character terminal piques the interest of the previously mentioned hardcore geeks and science researchers yet few others.

At my fall co-op job in '93, another student was showing off some new Windows 3.1 program called NCSA Mosaic. Using Mosaic, he pulled up some new documents he had just created for himself, and he called it his "personal Web Site" (fanfare). This page had some exciting tiled background, images of himself, spinning graphics, an under-construction graphic, and of course, blinking text that declared how he had made this page himself. Of course, there were the font size and color changes, heading changes, horizontal rules, and makes-baby-Jesus-sad color schemes. Little known to me at the time, he had made use of every single HTML tag that was available.

Okay, looking back, all good HTML designers know that he was committing grievous offenses to good Web design, but at the time, there was something very compelling and exciting about this Web medium. Little did I know that this "Web browser" and "World Wide Web" thing was really going to change the world. I'm sure a lot of people have similar experiences or revelations with the web, but let's come back to modern day, and talk about what makes the Web great and whether it's truly the be-all that some aspire to label it.

My first exposure to the Web demonstrates how easy it is, first, to get on the web and secondly, to have a web presence. Once you're in front of an Internet-connected computer (or device) with a browser open, all you have to do is know a Web address, type it in the address bar, press the Enter key, and wait for it to display. From a given page, there are typically links to other pages either local to the site and often external to the site. In the latter case, portal sites with numerous external links potentially exposes its viewers to vast seas of content. With enough time and the right portal sites, people are able to traverse this web of information, which obviously has become an interesting and compelling medium for users.

Ease-of-access is only part of the story for the Web's success; without compelling waves of content to surf, users would still be looking at a sea of flashing, colored text, animated GIF images, and under-construction signs. The success of the Web must be partly attributed to how easy it is to serve information. Setting up a simple, small-scale Web server requires little more than an always-on computer, Web server software (typically free, open-source), an Internet connection, and some network configuration. A web system can be scaled up from a small site that handle a tiny trickle of traffic up to systems that handle millions of browser requests per second, such as Google.com or any number of well-traveled Web destinations. While simplicity of setting up the delivery system (the server), what you deliver is equally important.

As demonstrated by my fellow student's first Web page, creating content is quite easy, requiring just a little bit of curiosity, experimentation, and a text editor. As he also demonstrated, I wouldn't even say that taste and aesthetics are required (though highly beneficial). As the Web has risen in use and popularity, additional content creation, delivery, and management tools have been built, providing things such as WYSIWYG HTML editors, scriptable/programmable/dynamic Web pages (e.g. JavaScript, Flash, PHP, DHTML), and style management (e.g. CSS). These tools are behind the modern Web, creating a more compelling place to surf.

While barriers-to-entry are low for content viewers and content creators alike, the Web is a limited medium. Take a few seconds and think about what a Web page actually is. Or you could see what Wikipedia has to say about the Web. Anyway, some of the key concepts you may have come up with are: documents, pages, images, videos, text, hyperlinks, and if you threw out Google, Facebook, or YouTube, that's fine too.

These key words you came up with (besides Google, Facebook and YouTube, smarty-pants) all take root from the Web's origins in text delivery, lending itself well to viewing documents and traditional-textual media like books, articles, newspapers, and magazines. This can been seen in the traditional media that have moved to web (New York Times at nytimes.com, for example), things like blogs (what you're reading now), microblogs (twitter.com), and RSS technology used to publish and syndicate news and news-like media via the Internet. The Web's ability to display two-dimensional graphical media, such as images and video, have adapted it well for the same media mentioned before. This should be obvious from the success of sites like Flickr and YouTube.

Now think about your world for a bit: who and what you interact with daily, how you interact with it. You wake up, address your appearance (i.e. wash, brush, dress), eat, go to work, interact with our cars, devices, machines, coworkers, and return home, interact with family, friends, home devices and machines. This discussion is about to seem even more esoteric, but bear with me a bit. Human languages are devised to help us communicate the richness of this world, the real world. We have words for all the various objects that you could encounter in your day. Words for things with which we interact (banana, friend, machine, home, book, shirt), words that describe different ways we may act on these things (eat, talk to, pick up, go, read, wear, give) or to describe an object's state of existence (sit, stand, exist, move, fall, tears).

In this world I asked you to think about, you may read a book, a magazine, or newspaper, or you may surf the Web, too. We could decompose Web surfing into activities like reading email, finding or researching a topic on Google and Wikipedia, looking at photos on Flickr, watching a YouTube video, or updating Facebook and catching-up with friends. Now, let's compare the richness of the world's verbs with the Web's verbs. World: eat, talk, pick up, go, read, wear, give, carry, put in, take out, sit, drive, fly, the list goes on and I encourage you to spend a moment to expand on this list. On the Web, we can: read, find, research, look, watch, update, catch up.

While the Web's list is not complete, you should find that the list is a marginal subset of the verbs we use in our world-at-large. My point here is that the web is designed originally support or emulate a subset of things we do in real-life. If we want to talk to friends via the web, new protocols and additions are made to extend the Web to do these things. Web chat and Web conferencing are examples of how engineers have tried to extend the Web to be-all, that is, be a solution to all things we can think of.

From a technical aspect, a major weakness of the Web is the HTTP protocol. HTTP implements a call-and-response paradigm. Essentially, when a user enters a Web address, the browser issues a request -- or call -- to the server. When the call is received, the server responds, sending the requested page to the user's browser. Alternatively, Web browsers can submit data (from login or billing information forms, for example) to a server. A page received by a Web browser may be embedded with references to other content (images, videos, sound clips, Flash applications, style sheets, and even another HTML page) that the Web browser will request in order to render the complete Web page.

This is all well-suited for user-initiated interactions, but this paradigm is also limited to user-initiated interactions, and is not suitable for systems that where other objects wish to initiate interaction with the user or wish to maintain a constant dialogue between browser and server. A simple real-world example is the telephone: if you wish to call someone, you dial their number, and the recipient decides whether to respond by answering the call. This is the same paradigm of the HTTP protocol. A browser attempts to open a call with the server, and the server responds if it accepts HTTP communications. A major difference is that telephones permit calls in the reverse direction, someone who wishes to call you is able to dial your number, giving you the opportunity to respond. On the Web, HTTP allows no way for the server to proactively contact your browser to send you a page that you didn't request. Plenty of crafty engineers have been put to work to build workarounds to enable such behavior. While there are viable solutions to some of these problemts, the fact remains that the Web is just not suited nor was it designed to do this.

A further limitation of HTTP is that, in general, connections are only maintained until the requested page or file is complete, after which the line is disconnected. In the telephone scenario, a received call establishes a connection that remains until one side hangs up or is disconnected. Imagine after making a call, you ask one question of the other party, and once they deliver their response, they politely hang up the phone. To ask another question, you have to call again, and for each question, you have to make an individual call. This is essentially what occurs with most Web servers.

This behavior actually makes a lot of sense in the context of typical Web browsing. A user will request a Web page via HTTP from a Web Server. Once the page has been delivered, the user will view the page for perhaps a number of seconds to a minute or even longer. Until the user clicks on a link, no further network communication is necessary, and the link may be with an entirely different server. In HTTP's intended mode of operation, maintaining the browser-server link is entirely unnecessary and ties up resources unnecessarily, which is especially bad if a server must simultaneously handle the requests for large numbers of browsers.

This makes HTTP, and thus the Web, ill-suited to applications where the client and server communicate in a dynamic dialogue. A common scenario is when the server maintains the state of a dynamically changing system, and the client (browser) displays a view of the server's state. Email clients periodically poll a server to see if new email has arrived. Another example would be the watching a live sporting event from the client. As points are scored and participants move around the field, the client would see the live score and could watch the action take place.

The ideal solution is for the server to pass state changes to client once it is aware of a change in state. When the server receives a notice that a team has scored, it immediately transmits this information to all it's clients that are watching this event. This solution is highly efficient, since communication transmissions only occur when the server state changes.

With a client-initiated call-and-response system, the common solution is that the client must periodically poll the server for information. To get adequate real-time information, the client must request information once-per-second, or perhaps faster. With multiple clients, this leads to heavy workloads for the server to service each client request every second. Worse, if the state has not changed, the client and server communicate that no change has occurred. Such communication provides no value to the client or server; the bandwidth and server cycles are wasted. Clients can tradeoff real-time accuracy of server state by decreasing the frequency of polls. At the far end of this tradeoff spectrum, a client is only sure of the accuracy of its state after a poll. For a system state in high flux, this accuracy could be gone a mere instant after the poll. All of these tradeoffs and inefficiencies can be avoided by staying away from HTTP in these scenarios.

I'm a high-use Web user, and so I appreciate the ability to receive digital media from a wide-range of content providers. It's easy for me to access that media; I just launch a browser while connected to the Internet, enter the Web address, and a second or two later, it's there. Due to the low barriers of entry and it's scalability, both home users and corporations can easily build a Web serving infrastructure. The simplicity of HTML allows content creators to get started easily making their first web pages, while advanced tools such as JavaScript, CSS, PHP, DHTML allow more ambitious creators to create and manage compelling content.

Despite the advancement of tools, the Web and HTTP was designed for a purpose and to operate in a specific way. With the best of intentions, engineers and corporations have attempted to reappropriate the Web to fit their every need, but there are limits to what can be done. The Web is founded on a two-dimensional, text foundation with a limited vocabulary of interaction. Also, the Web's underlying protocol, HTTP, is designed primarily for call-and-response, short-lived communications, instead of enduring dialogues. Engineers who wish to expand the Web's purpose or who need to make it work in ways beyond those originally intended face serious challenges, as they're essentially trying to make a square peg fit in a round hole.

There is much we can learn from the success of the Web and its design, however engineers are asked to shoehorn the Web to fit our every need. The Web is not and should not be asked to be the be-all end-all of the Internet.