[joesavage]

Author here. It’s definitely true that extending existing browsers is the fastest route to this kind of behaviour (though it’s not clear to me if it’s the best route). In fact, if you squint a bit (or maybe a lot), it could be argued that with application-specific URL schemes we kind-of sort-of already have the primitives we need to make something like this work.

Practically, though, if you want the multi-program side of this (which is kind of orthogonal to the 'multiple perspectives on how things are connected' side), then to make this kind of multi-window hypermedia system usable I think you need to have deep integration with the window manager. While Chrome OS tries to achieve this kind of integration by making the browser the OS, I propose that the best way forward here is to effectively make the OS the browser, as I discuss in the article. (Of course I’m not talking about the kernel when I say ‘OS’ here, but the desktop environment). At that point, I’d say the browser is different enough to the browsers of today that the description of ‘freeing the Web from the browser’ is still accurate.

[icc97]

Thanks for the reply! It's a really interesting piece of research. Yes, you're quite right, the browser alone can't interact between all the programs, I was purely thinking of low hanging fruit for the browser plugin.

I watched a Google interview with Douglas Engelbart [0] where people asked him a couple of times if Wikipedia was what he'd envisioned for hypertext, he was very polite about it and said it "was a good start", but he'd clearly wished that we'd got much further by now.

What you're suggesting is definitely a step forward.

[0]: https://www.youtube.com/watch?v=xQx-tuW9A4Q

[feanaro]

The multi-program facet of this reminds me of Plan9's [plumber](http://doc.cat-v.org/plan_9/4th_edition/papers/plumb) concept, which is an OS component allowing communication between programs in the form of "plumbing messages". The plumber processes plumbing messages according to a rules file, passing them on to other applications. This rules file allows the user to easily configure which piece of data gets delivered where in a uniform fashion.

Plan9's plumber was mostly text data oriented, but it could in principle work with any kind of resource (images, audio files, documents). It seems naturally extensible to URIs. It goes a bit deeper than your idea by saying URIs and browsers aren't special and that all kinds of data should be plumbed between all kinds of applications (for instance, a text editor detecting a DOI in a text file and converting it into a clickable link that sends a plumbing message to the browser, which would then open the corresponding doi.org page).