In June of 2003, getting on for two years ago, I compiled my third-year project at Warwick university. It was an insanely ambitious, typically over-the-top scheme, predicated on an absurdly vain notion: the web is all wrong, and I know how to fix it. Oddly enough, since then, everybody seems to have been agreeing with me* -- at least the first part.
One of the problems with the nature of the web is that while the web itself is distributed, individual web sites are not: popular sites are subject to the Slashdot effect and other major events which cause flash crowds and overload the server. ... [The problem] is simply that the client-server model is not adequate for such a highly volatile environment as the web. Enter WebTorrent. A computer with WebTorrent will access websites by their ordinary URLs. If a user wants a web page that no one has downloaded recently, it is downloaded directly. If lots of users are viewing a website, however, the WebTorrent clients are able to discover each other and download the site from each other using P2P methods. The result is distributed web caching. Particularly interesting is the fact that since this model requires no changes to the website itself, it is not a method of distributing a single website, but it simultaneously solves the same problem for the entire web. The more WebTorrent clients exist on any network, the more useful and robust the network becomes.
Coral first came to my attention in August 2004. From their website:
CoralCDN is a decentralized, self-organizing, peer-to-peer web-content distribution network. CoralCDN leverages the aggregate bandwidth of volunteers running the software to absorb and dissipate most of the traffic for web sites using the system. In so doing, CoralCDN replicates content in proportion to the content's popularity, regardless of the publisher's resources---in effect democratizing content publication.
Coral is an implementation of WebTorrent, built by people much cleverer than me. Instead of distributed proxies, they decided on a single proxy at a central point -- a design flaw, in my opinion, which has decreased the usefulness and the popularity of the service, since the proxy itself can be (and was) itself Slashdotted by sudden loads.
Strike 2: Ajax
Oh well, not very concise, but it'll do. Why is Ajax useful? Because it is circumventing the document-centric nature of the web. What is the document-centric nature of the web? Again from my report:
HTML has a problem in that it is document-centric. ... HTML is designed for the express purpose of describing a single document: it is structured to define the head and body of the document, and sections within the document. ... This document-centric approach produces, in even fairly small sites, a large amount of repetition. As individual websites grow, the task of maintaining a coherent "look and feel" across hundreds of similar pages manually becomes laborious and time-consuming. To solve this problem, an entire industry has sprung up: the field of Content Management Systems (CMS) ....
And why is this a problem when designing a web application? As I said in the report:
The web is not designed to provide the level of user experience required for desktop-like applications: these require almost immediate response to user action. This is another effect of the document-centric nature of HTML. Applications generally provide a largely stable user interface with minor changes as a result of user action. HTML is not equipped to provide incremental changes to an interface; to change an HTML page it is necessary to re-describe (and hence re-transmit) the entire HTML document. This is both slow and inefficient.
Or as the coiners of Ajax put it, 20 month later:
Obviously, if we were designing the Web from scratch for applications, we wouldn’t make users wait around. Once an interface is loaded, why should the user interaction come to a halt every time the application needs something from the server? In fact, why should the user see the application go to the server at all?
So, you can see why I'm beginning to panic. I'm sitting on a report full of fabulous ideas, but I'm not implementing them, and other people are finally getting around to it. So it's time to take action. It has to be now: the technology is finally here in the browsers, the web development landscape is finally beginning to change with Ajax. A bucketful of technologies have been developed since I wrote my original report, which have done a lot of the heavy lifting for me. So I've taken it upon myself to start implementing Web2. I'm doing it because it's useful, I'm doing it so I get the credit, but most of all I'm publishing it, in the most public forum that will have me. The alternative is, after all, to be damned. I'm establishing prior art: no one (I'm looking at you and you, here) is going to patent ideas I came up with years ago and prevent others from using them. It's public domain and/or bust.
So hop on over to that URL to see an introduction to the very first part of one section of web2, which I implemented this weekend.
What I got wrong
This wasn't obvious, for a number of reasons:
- The XMLHttpRequest object. Frankly, if I'd known it existed, I'd have started work on this much sooner. Better late than never.
For the remainder of the blurb on web2, including what it does, what it will do, and what else I have planned, head on over to the web2 site now.
* Yes, I'm aware this all reads a lot like the ramblings of an arrogant child prodigy. Hopefully, it'll make everybody respect me as much as they do him. More so, since I'm older, dammit.