This would only be the case if all the rich people happened to carry their vast wealth around as cash in order to avoid the tax collector. They don't. They keep it in banks and investments.

Does this help?

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"></script> <script type="text/javascript"> if (!("jQuery" in this)) { document.write('<'+'script type="text/javascript" src="query.min.js"></'+'script>'); } </script>

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.