[AoyW] Embracing & Extending Bill

It is a long fall from the internet clouds, where web pages coalesce into sites, to the PC continents, where documents accrete on disks. True, a browser can present a traditional document retrieved from a web site by invoking a local PC app to take over the browser, though editing it is futile. Newly extant are browser-based office suites enabled by AJAX, in which the app itself is remote, and just vaguely familiar. But rare is the PC app that is a component of a web page (leaving aside the Flash plugin). And utterly extraordinary is a locally stored web composed of ordinary, editable office documents, interlinked to form a site.

This is a sad state of disunity, the moreso because a mechanism to remedy it has been widespread for more than a decade, and built into Microsoft Office and most other PC apps: Object Linking and Embedding, a.k.a. OLE. Using OLE, knowledge workers could employ well-known apps to assemble project webs, and cease scrambling around desktop/server folders and email attachments to find related files. They are obstructed by the lack of a browser that is an effective "OLE container", to manifest web features around otherwise isolated documents.

Far from giving more control of the web experience to Microsoft, this approach embraces and extends its apps, leveling the field for new challengers in the knowledge-tools game. In these unified webs, server-side editors (which interact continuously with the user just like desktop apps) co-exist with traditional editors. That combination enables all kinds of web-styled solutions, in which users leverage well-known tools, and needn't fuss with relearning a word processor.

Happily, OLE-defined content can be viewed without the original editors, and could be modified without them using server-side editors. But how, you may ask, would desktop apps that were coded to write files send content back to a net service? The browser-container must catch the read/write requests of embedded apps and transmit them via HTTP; XDrive and other online storage services use this mechanism.

This "net service" is likely a background process on the user's phone or pocket server, which also delivers the web pages on which the OLE apps are embedded. Note that when pages in a project web are published to the worldwide web they would be translated to XHTML, SVG, etc. as is common practice.

[AoyW] Talking to the Web Server that Just Walked In

A peripatetic web server can't just tack up a sign on the nearest wall reading, "Hey, I'm the cool new site in this room! My IP of the moment is 192.168.0.101." So how do you talk to the web server running on your wi-fi handheld using a friend's laptop at the coffee shop? It's a case of "Don't call us, we'll call you—often".

A wandering web server has to sing "here-i-am" periodically on the local network. Potential clients have to listen for that tune, which will come across on an agreed port. However, contemporary browsers aren't prepared to listen for anything except responses to requests they've posted to known servers.

Fortunately, the solution is trivial. All we need is a faceless desktop app, with an icon by the taskbar clock, that tunes in that port, taking down the info for any web server that chants. When you want to talk to one of them, you click the icon to view the list of singing servers, and hit the one you aim to chat up. That starts a browser for the server in question.

Our current airWRX prototype uses this technique inside its client component, though now I wish we'd separated it out as described above, so anyone could grab and reuse it in their own projects. (That wouldn't be much work, so if interested, drop an email to airWRX->networkimprov+net.) The server singer can be implemented in a one-line pearl script, or a brief C program that runs from the command prompt or in its own thread in a larger app.

You'd think that this scheme would already be specified somewhere, for instance Apple's Bonjour protocols for ad hoc IP networking. But as far as I can tell, it assumes that services are lethargic beasts, whereas clients flit about; the fleas must seek the dogs. In the case of a web server running on your laptop or wi-fi handheld, it's the ephemeral animal. If clients constantly call "are-you-there" looking for newly arrived or departed servers, a room full of clients would waste a lot of the available bandwidth. It's more logical to have the servers do the talking.

[AoyW] TiddlyWiki, an Offline Browser App

A reader recently pointed me to TiddlyWiki, a Javascript notetaking app that runs in a browser but has nothing to do with a server; it saves changes to its HTML content to a local file. Though prosaic in the PC experience, this is such a strange idea in the web world that many people require real time to grok it!

TiddlyWiki's presentation concept is also unusual; it acts like a collection of blog entries which are displayed in an arbitrary order according to how you hit item links. Items are inserted into the page as you click, which is certainly preferable to popping up windows or loading whole new pages for small snippets of content.

The javascript code is tiny, under 200K, so naturally it fits on a flash drive. However, it does require a newer browser, so storing a browser on the flash drive as well might be recommended. This is possible with FireFox, which has a portable configuration.

TiddlyWiki delivers only part of the web experience to personal notetaking: hyperlinking within a single page. That's a feature now conspicuous by its absence from most desktop software. However, the notion of a web (interlinked pages, each with definite content) is absent from this "web app". If a wiki is an edit-in-place web, then TiddlyWiki is not a wiki at all, it's a structured text collection with a fixed schema and full-text (non-indexed) search.

Also missing from the standard web experience is any kind of multi-user access, since it's bound to a single browser. You can upload a TiddlyWiki HTML file to a web server to simply publish it, which is how their web site is built. Shared entries which propagate to a server or peers automatically would make this a much more interesting environment. Also useful would be a way to incorporate non-HTML content, e.g. a table of numbers clipped from a spreadsheet, or some SVG for a pie-chart.

[AoyW] Hosting Holds Web Evolution Hostage

The worldwide web is essentially a collection of centralized servers, albeit distributed at a variety of hosting sites. A tiny number of web servers are sited outside data centers. A handful of non-web online apps employ decentralized servers, mostly as a way to avoid crushing demand on a single site for audio/video.

People want to use the web for more things, like everyday work. Its info-model and ease-of-use are compelling. But its centralized architecture is only suited to certain applications, like mass-market media, whizzy mail-order catalogs, and clubs which meet in e-text; a.k.a. "content, commerce, community".

By contrast, the dominant architecture for everyday work is decentralized: the PC. Given the headaches of a certain widespread PC OS, IT managers fantasize about centralized blade servers and display terminals. The proliferation of laptops and flash drives and smartphones clearly points the other way. In short: No, Mr. McNealy, the network is not the computer.

The { web = hosted } mindset is now an obstacle to the evolution of the web. It's a modest leap of imagination to see that the web becomes an everyday work environment once implemented on a decentralized architecture: peer-to-peer. This means web servers that live on user devices (especially mobile ones), hit local screens with their apps, and synchronize with others belonging to afilliated users whenever they can access the net.

Yet I've found this concept to be challenging for people. A pocket web server sounds like a contradiction in terms; I might as well have claimed to have a self-contained internet on my keychain. Folks have trouble separating the web info-model (multi-format, interlinked pages), from the architecture on which it is now deployed (centralized servers). That very separation has to happen for the web to make a difference in everyday work.