[
Lists Home |
Date Index |
Thread Index
]
On Saturday 26 January 2002 11:06 pm, Paul Prescod wrote:
> That's still the central idea of the Web and its most impressive
> feature. So I stand by my claim that the Web that we have is exactly
> a subset of what Tim Berners-Lee dreamed of back then.
I'm basing my opinion on what I've read, and what I saw in the very early days of the WWW. Perhaps Tim was down-playing the grand vision then...
> As far as what HTTP was designed to support:
. . .
> * http://www.ietf.org/rfc/rfc1945.txt
1996. HTTP1.0 [3] HTTP2 [2] or HTTP 0.9 [1] also make good reading.
Note in HTTP 1.1 [4] section 1.4 and the section claiming backward compatibility with HTTP/1.0.
> http://www1.ics.uci.edu/~fielding/pubs/dissertation/web_arch_domain.
>htm
Well I lived through some of the history you quoted, and I don't remember it being quite so organized... more like HTTP 0.9 wasn't enough, HTTP2 was too much, splintering, some consolidation, then the IETF working groups. While Roy may claim to have spearheaded HTTP development, I don't remember him emerging until somewhat later in the play (Dan, Larry et al. all played a huge role too).... though from late '94 on, his presence was certainly (and increasingly) felt.
> "The next chapter introduces and elaborates the Representational
> State Transfer (REST) architectural style for distributed hypermedia
> systems, as it has been developed to represent the model for how the
> modern Web should work.
. . .
> "Since 1994, the REST architectural style has been used to guide the
> design and development of the architecture for the modern Web.
. . .
> Well either you weren't watching closely enough or Fielding is
> engaging in revisionism. Insofar as I read the HTTP and URI
> specifications and I see evidence of design and architecture exactly
> as he describes it, I am inclined to believe him when he claims that
> it isn't there by accident.
I'm not claiming that HTTP 1.1 and the later URI specs don't represent REST principles or Roy's thinking. That said, I don't think Roy had formulated them in 1994, and certainly didn't articulate them. One way or another, I certainly don't think he led HTTP development based on consistent application of those principals. Many others were involved.... the http mailings lists [5][6] show that much at least (and many of the older lists are incomplete anyway).
> So you're saying that it is okay to say: "XML can be used for
> purchase orders" but incorrect to say "XML supports purchase
> orders." I consider those two statements to be logically equivalent.
I don't. It's kind of like reification, where you start using a label as though it represented the thing itself. Saying "my car can be used for bulldozing" and "my car supports bulldozing" aren't the same thing (should see the damage a deer did to it ;-)). Saying "HTTP can be used for <whatever>" is not the same as saying "HTTP is/supports <whatever>". Maybe I'm just being overly-sensitive, but to me "supports" implies "intrinsically", or "is designed for" or "is suitable for". Anyway, I'd encourage you to be explicit when talking about *applications* of the protocol, vs. the protocol itself.
> Funny. Neither does the SMTP spec. In what sense is SMTP
> asynchronous? You connect to a server. You set up a socket. You talk
> back and forth on it. Just like HTTP. In fact, SMTP has more
> syncronization points in a connection than does HTTP.
SMTP is store-and-forward (different from asychronicity per se., I agree. We might say "message transfer is asychronous" perhaps). The early HTTP specs were pretty much explicitly not store-and-forward, and indeed, pretty much explicity synchronous in the request/response *and* message transfer [1][2][4] and HTTP/1.1 claimed/claims backward compatability to HTTP/1.0.
(I remember someone categorizing HTTP as "an American protocol" because "you shake hands, do your business, and then say goodbye!")
I think the loosening of interpretation to be a good thing (always good to review things in a new light), but I also think it an entirely modern phenomena.
> When did anyone say that HTTP billed itself as a replacement for
> SMTP, SNMP or RPC? All that's been said is that it was designed to
> be generic which means it could be used as a replacement for those
> things.
...and people are claiming it not only *can* but *should* be. Again though, it's not HTTP so much as *applications* of it... which obviously *can* replace the other protocols (all you need is GET/POST after all). This distinction is critically important, so again, I'd beg your indulgence in making the difference explicit when you send out messages.
Whether it *makes sense* to use HTTP is another question... I'm open minded on this one.
> > 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.
>
> This:
>
> * http://www.w3.org/Protocols/rfc2616/rfc2616.html
>
> Is a slight improvement over this:
>
> * http://www.w3.org/Protocols/HTTP/AsImplemented.html
>
> Are you kidding?
No. On a number of axis, they appear largely the same philosophically/architecturally, especially when you see [2] as well. Ultimately, to the end-user, they offer similar functionality (get me some content), and largely the same system model.
> In what sense are 7 new methods, persistent
> connections, a completely new data model, support for intermediaries
> like caches, etc. a "slight improvement"?
Functionally, yes. HTTP/1.1 is vastly more complicated than 0.9, but there are (significant) parts of it that aren't used much (methods, headers, etc). Bloat doesn't make a good spec.
> Roy Fielding has documented how and why HTTP 1.1 is radically
> different from HTTP 0.9. He and Tim B-L have described the design of
> the architecture of the Web that you claim was not designed.
Yeah, yeah. It's nice to keep a notebook. Reality is borne out in the mailing lists, in running code, and in politics. I don't see any mention of REST, or it's codified principles anywhere there... at least not until fairly recently. Also, it's easy to codify something *after* it's running. That's evolution, not design. Maybe the general principals (like URI's) were there, but the rest happened organically.
One last thing: it's entirely possible that I don't remember perfectly, but on the other hand, I *am* going from memory of events I watched or participated in...
---
[1]http://www.w3.org/Protocols/HTTP/AsImplemented.html
[2]http://www.w3.org/Protocols/HTTP/HTTP2.html
[3]http://www1.ics.uci.edu/pub/ietf/http/history/draft-fielding-http-spec-00.txt
[4]http://www1.ics.uci.edu/pub/ietf/http/history/draft-ietf-http-v11-spec-00.txt
[5] http://www1.ics.uci.edu/pub/ietf/http/hypermail/
[6] http://groups.yahoo.com/group/http-wg
|
