[
Lists Home |
Date Index |
Thread Index
]
On Saturday 26 January 2002 05:34 pm, Paul Prescod wrote:
> HTTP is the protocol designed to support the Web. According to Tim
> B-L, the "Web's major goal was to be a shared information space
> through which people and machines could communicate." How much more
> scope could we attribute to HTTP than that?
Yes... and the original design was for a much smaller scale community
of physicists.
> But really, I don't see the point of the Web anthropology.
The point is that your claims smack of selve-serving revisionist
history. Claims like "HTTP was designed to support..." and "the WWW
was designed for..." followed by some grandiose claim like broadcast,
asynchronicity, or "HTTP was designed in the REST paradigm.." simply
aren't borne out by history (and I have been involved directly, or
peripherally since Tim BL sent out his first email announcement). I've
seen enough revisionism that this truly annoys me. Your claims for
what HTTP can be made to do, are sorely clouded by this... as are
Mark's. This is unfortunate because I think there is value in the
claims... and the vision that you are both espousing.... certainly to
the point that they need to be weighed objectively.
> One is to have a single, unified address space for all information.
I agree with that. It was Mosaic that allowed millions to exploit it.
That URL's *were* useful is beyond debate, that they will *continue*
to be useful remains to be seen.
> > and fail to see that HTTP+a set of application/URI-space semantics
> > isn't the same as HTTP itself.
>
> That's another semantic game of little relevance.
So you say. I think
"HTTP supports asychronicity."
and
"Using HTTP to call an application, you can support
asynchronous messaging"
to be *vastly* different statements. One implies HTTP *intrinsically*
supports the functionality, the other that it can be *integrated* with
the functionality. IMHO it is dishonest to play semantics games by
calling these equivalent.... just as with making inaccurate claims of
history.
> Can XML be used for purchase orders? Yes.
Yes, but it does *not* support them itself. Nowhere in the XML
specification does it define "XML for purchase orders". Purchase
orders and XML are logically distinct.
> Can HTTP be used for peer-to-peer communications? Or asynch
> communications? Or reliable communications? Yes. In exactly the same
> sense.
Precisely. Nowhere in HTTP does it say that it can be used
asychronously (though like GET bodies, it doesn't forbid them).
Nowhere in the HTTP spec does it claim to be a replacement for SMTP,
ot SNMP, or RPC. Does it support those *applications*. Yes. Does it
suport them in and of itself? No.
>I don't see the analogy at all. If I understand the suggestion then I
>would object to it not on the basis of any detail of the
>implementation of HTTP but on the fact that it violates web
>architecture as I understand it. GET takes a URI because HTTP is
>address-centric.
Yeah, I've already heard that. There was a time when query and URL
parameters were looked upon differently.
FWIW. I'm not claiming the idea was good, just that I've seen both
sides of HTTP functionality argued.
> What is the relevance of this "original HTTP"? HTTP was re-designed
> from the ground up. I'm talking about HTTP of today.
OK. So when you say "HTTP was designed to support..." I would like to
ask "When?". Which *precise* version of HTTP should we be talking
about? How does it differ from HTTP 0.9?
To me, there is HTTP 0.9, and a number of revisions.... HTTP 1.1, to
me, is a vastly more complicated, and slightly improved version of
HTTP 0.9.
|
