Once we get sites to support the additional headers to provide the client with a Jabber/XMPP address to negotiate updates with and a key to concurrently download the data via a distributed hash table, we’ll need a browser and subscriber that support them.
Possibly a modified version of Firefox, the nuWeb Browser would take advantages of these two headers in various ways.
First, web pages and RSS feeds could be automatically refreshed when content changes, no polling required. When the page is visible or the feed subscribed, the client sends a subscribe message to the address specified by the host. When the document updates, an instant message is sent directly to the browser and the browser reloads the page. We could even provide DOM updates so no actual re-rendering is required.
With this a user could go to the homepage of a news site and watch the headlines instantly roll in to the page, or watch a wiki page update instantly. Comments on pages could appear as they’re posted, et cetra. No polling is required for RSS feeds; the client gets pinged when its time to do so. No more, “Are we there yet?” bandwidth wastes.
Second, when a document has the hash header, it begins to concurrently download the data via the distributed hash table. Since the data from the host is in order, the data from the distributed hash table could be sent in reverse order. When the combination of the host’s data and the DHTs data combine to form the original document, you’ve got yourself the file quicker than just waiting for the host to transfer the entire thing by itself.
This will be insanely great for sites that get slashdotted or host large files. And, unlike BitTorrent, no special software is required and the content can be displayed inline. In fact, clients that aren’t nuWeb-compatible will still be able to download the data, since it’s still just a regular HTTP transfer. And, we’ll be using the DHTs routing, so no BitTorrent trackers are needed, either.
In fact, I recently discovered that DHTs can be used to provide arbitrary key-value relationships, so we could store metadata into keys that represent URLs, eliminating the need for the host to support the technology. Then, we can create hosts that poll pages and perform the publish-subscribe instant messages externally from the host that’s at hand.
Ultamitely, we can provide backwards compatiblity in both directions:
- nuWeb-enabled hosts that support traditional clients
- nuWeb-enabled clients that support traditional hosts
I know I hate HTTP, but it looks like I’m going to have to realize that it does serve its purpose. So, these extensions to it will simply make it better.
