From the very PDF you link to, Question 1, right at the beginning:

(Emphasis mine.)

Do you have any links for this? I checked my local traffic regulations (Cambridge, MA) a couple of weeks ago and didn't see any language at all that hinted that traffic lights might be optional for cyclists.

The paper you want to read is Max Tegmark, "Parallel Universes," 2003. Available here: http://arxiv.org/pdf/astro-ph/0302131v1

"Abstract: I survey physics theories involving parallel universes, which form a natural four-level hierarchy of multiverses allowing progressively greater diversity. Level I: A generic prediction of inflation is an infinite ergodic universe, which contains Hubble volumes realizing all initial conditions — including an identical copy of you about 101029 m away. Level II: In chaotic inflation, other thermalized regions may have different physical constants, dimensionality and particle content. Level III: In unitary quantum mechanics, other branches of the wavefunction add nothing qualitatively new, which is ironic given that this level has historically been the most controversial. Level IV: Other mathematical structures give different fundamental equations of physics. The key question is not whether parallel universes exist (Level I is the uncontroversial cosmological concordance model), but how many levels there are. I discuss how multiverse models can be falsified and argue that there is a severe “measure problem” that must be solved to make testable predictions at levels II-IV."

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.