A problem for "Web as distributed programming paradigm"

Russell Turpin deafbox@hotmail.com
Fri, 24 Aug 2001 14:46:36 +0000

I wrote:
>>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 

Clay Shirkey responds:
>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. ..

Maybe it is The Right Answer<tm>. It certainly has proven
a good answer.

But. (And you knew there was a but, right?)

(1) Some people are looking at REST as a programming
paradigm. If the the answer above is right, then REST is
NOT a programming paradigm; it is merely an IPC protocol.
Maybe that is all it needs to be. I'm just pointing out
the conflict between (a) The Right Answer<tm>, as given
above, and (b) higher aspirations some folks have for

(2) In fact, there are lots of reasons we should want
The Right Answer<tm>, with regard to coupling distributed
programs, to provide a general programming paradigm. The
big reason is that it allows us to separate architectural
concerns from program structure. In the case of COM, I
can think about how I want to structure an application in
terms of business objects (both mine and foreign ones),
and separately think about how these will be hosted and
the related architectural issues. OK, OK, that's not
entirely true. I don't like COM, and I know the picture I
draw is more "in theory" than "in practice." But it's the
example that people know, the theory is mouthed, and in
practice, it helps, even if it is far from perfect. If I
use a COM object that some other company provided on a
distant machine, and they fold, I can reimplement the
object locally with little problems beyond the actual
doing of that. Or in iterating on the planned architecture,
I can comfortably move COM objects around, without worrying
(too much) that that will affect the programmers hard at
work in the next room.

The fact that HTTP is (currently) an IPC mechanism removes
that flexibility. That distant website folds and you want
to provide the service locally? Gee, Bub, were you planning
on running and maintaining a web server locally? Well, uh,
that's a bit of a problem. The program structure becomes
tightly coupled to the architecture, and even if The Right
Answer is right for a lot of big reasons, that consequence
is A Bad Thing<tm>. (Not being religious, I have no faith
that perfection is possible, and so I'm content with the
possibility that The Right Answer<tm> has some Bad
Consequences<tm>. And I will call them as I see them.)

(3) The careful readers of FoRK will notice that I have not
made any inherent criticism of REST, but only of how it is
currently implemented and used. Maybe, if we were to implement
a Web server as programming environment, with efficient
implementation of local requests (bypassing the IP stack),
then we can give the desired transparency of machine
boundaries to software builders. Would this be A Good Thing?
Is REST (rather than SOAP) the right protocol for this? Beats
me. But until something like this is done, or at least
proposed, we're discussing IPC protocols, not programming
paradigms. Or so it seems to me.


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.

Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp