A problem for "Web as distributed programming paradigm"

Clay Shirky clay@shirky.com
Fri, 24 Aug 2001 09:30:41 -0400 (EDT)

> But even if I ran a local webserver, and even if using it for
> program decomposition weren't dirt slow, I would be hard pressed to
> think *why* I might use HTTP to structure a program, [...] I always
> and only use it where IPC might occur. I never view HTTP as a
> general way to structure software.

But why isn't this the Right Answer<tm>?

One of the things that attracted me to REST is the intuition that the
internet is different. Sun aside, the network in fact is not the
computer, because there are things we expect to be true on a local
machine -- high availability of resources, low latency, shared clock,
the ability to search exhaustively for data, the putative validity of
any user request -- that are all challenged by the net.

A distributed programming environment that relies on the single-
machine model has limits to scale. In small or homogeneous
environments, (a LAN running all Windows2000 boxen, say), you can get
away with this, but in large heterogenous environments, issues of
latency and unreliability mean the only way to have a truly
distributed programming environment is to treat all calls as if they
were network calls, and forgo any of the advantages of the single-
machine model.

Blech. So (my read of) the REST way -- keep state local, and use http
as a kind of inter-state highway -- seems like a permanently good
solution to a large class of problems.