Do you have a reference for that?

A Fire Upon the Deep is definitely better, as is A Deepness in the Sky. Both are very well worthwhile; in fact both number among my favourite science fiction novels.

You tell a convincing tale; but why would anyone do the required rewriting by hand? The rules you mention sound very much within reach of the kinds of things obfuscating rewriters -- or compilers in general, for that matter -- do. I mean, if expensive, pointless adherence to some bureaucratic mandate is the aim, of course. Solving the problem wrong, indeed.

You're welcome! Enjoy.

Slavery is a different kettle of fish, don't you think?

Again, enjoy. I hope you recover some motivation soon.

If you weren't aware that your browser already has very rich network interaction capabilities, I suggest reading up on AJAX. Reversehttp, when running in a browser, is built from sandboxed javascript code, running in a page, using XMLHttpRequest, just like everything else.

It's also not actually browser specific, and applies equally well to thick clients (think Skype, or practically anything that wants to receive messages rather than just send them; you might make a broad comparison with UPNP or STUN). It's just a happy coincidence that it can be used to lift the browser up to equal status with other programming environments.

Well, the next time you, your girlfriend, daughter, mom, dad etc writes a web service, perhaps they'll get some leverage out of it :-)

(One interesting demo, not linked on the site but present in the source code on github, is a PubSubHubBub endpoint in the browser, which can subscribe to PubSubHubBub's feed update notifications for real-time feed tracking. (PSHB deliberately doesn't include any long-polling ad-hockery, so this is otherwise not possible.) The URL of the page is subscribed to the PSHB hub, and when new atom entries arrive, they're POSTed directly to the page -- or rather, as direct as possible given that there's the reversehttp gateway relaying the POST on.)

You've missed the point: this is one of the situations when reversehttp actually saves the day. The reversehttp gateway is outside the firewall. Services inside the firewall contact the gateway to get it to relay requests in to them, using long-polling (or any other method, current or yet to be invented). The point is that the gateway is in exactly the right place to dole out names/URLs and to handle the routing, filtering and relaying.

Anywhere you'd otherwise be configuring apache/DNS/firewall/CGI/reverseproxy rules by hand. There aren't any protocols for that other than reversehttp yet. The goal was to make it as easy to get a name/URL and become a full server in the HTTP network as it is to anonymously participate as a client. Particularly interesting is the way it makes short-lived services suddenly viable: previously, you'd either have to reconfigure your gateway apache instance (or similar) each time a service came and went (or moved!), or ad-hoc up some way of doing roughly what reversehttp does, but on a case-by-case basis.

(It's also, by the way, no more difficult to secure the gateway than it is to secure any other web service -- the demo server hands out URL space pretty freely, but obviously if you were deploying it yourself you'd apply normal HTTP access control policies to limit who was allowed to register which names and so on.)

It'd be useful in the same way decentralised version control systems are useful by comparison with their centralised counterparts. The replication topologies are no longer constrained to the simple hub-and-spoke model. Think google wave, without the centralised server. Think google docs, without the centralised server.

There's nothing that limits reversehttp to the browser. Any HTTP client library can use it. The demo implementation has clients not just for browser-hosted Javascript but also for Python and Java. Besides the clients included with the demo implementation, Paul Jones has written hookout, for Ruby programs, and Tatsuhiko Miyagawa has written AnyEvent-ReverseHTTP for exposing HTTP services via reversehttp from programs written in Perl.

Huh? Did you read the spec draft? The metacircular use of HTTP is a cute hack, but in no way central to the idea. If you like, think of reversehttp as a kind of "remote CGI" -- like what people already do with apache's reverse proxying, but dynamically configurable.

Yes :-)

What if the other user's browser is the original source? Think something like Tiddlywiki instances running in the browser and synchronising peer-to-peer.

From www.reversehttp.net:

"[...] we need to be able to act as if being able to respond to HTTP requests was within easy reach of every program, so that we can notify interested parties of changes by simply sending an HTTP request to them. This is the core idea of web hooks. We need to push the messy business of dealing with long-polling away from the core and toward the edge of the network, where it should be. We need to let programs dynamically claim a piece of URL space [...] and handle requests sent to URLs in that space [...]. Once that's done suddenly asynchronous notification of events is within reach of any program [...], and protocols and services layered on top of HTTP no longer have to contort themselves to deal with the asymmetry of HTTP. They can assume that all the world's a server, and simply push and pull content to and from whereever they please."

The details of getting the requests through the gateway to the serving application are pretty trivial and interchangeable. The new idea is in registering endpoint names. UPNP and STUN cover some of the same space, but IP's addressing is fundamentally different to HTTP's URL-based addressing in that it's possible with URLs to have recursive delegations of portions of the namespace -- something that IP just can't do (because it's flat).

Because nuclear weapons are morally indefensible.