From: Jeff Bone (jbone@jump.net)
Date: Wed Mar 15 2000 - 18:41:03 PST
Imagine that the method isn't called GET, it's called INVOKE. INVOKE is a method
call. It takes parameters --- arbitrary, N-ary arglists. You can pass whatever
parameters you want. If you want something slightly less tedious and more
efficient, forget GET and consider POST = INVOKE. But truth be told, you *could*
encode everything on a GET string. (Not that you'd want to -- hence the
"perhaps.") Yeah, it's a bit of a reductio, but certainly if 1 method (GET) can
do the job, then 2 methods (one with a body / payload) should suffice.
jb
> Amen brother!
But can I get a hallelujah?!?!?
> So are smoke signals. 8-)
Party pooper. And yeah, sure, you can write anything you want using SKI
combinators, too, but why bother?
> Except that then you're using HTTP as a transport protocol, not a transfer
> protocol. Kinda defeats the point. If you can do everything with HTTP what
> does RPC buy you and why does it need to be anywhere, let alone on top?
>
RPC buys you a common interface abstraction. (In this case, I'm speaking
specifically of URLs as method selectors / arg lists, and RPC as something like
XML-RPC over HTTP.)
The point is that (a) HTTP *is* the new transport --- gasp --- the IETF illuminati
will be highly offended, but let's get real --- that's the implication of all the
firewalling etc. that happens in the real world. (b) The exact point is that RPC
semantics are on top of HTTP, sure you can build those willy-nilly but a nice
standard helps.
So your point is valid --- why HTTP instead of i.e. pure TCP, port-per-app, etc?
I can only appeal to my (admittely subjective, probably flawed) perception of the
"real world" in explaining why moving the bar up to HTTP for transport would be a
good thing. Human readability / parsibility. Availability of lots of reference
implementations and utility code. Etc. etc.
> For the most part, I'd agree with you; most HTTP extensions I've seen are
> so much crapola because the extension methods make no sense in the
> architecture
> of the Web; document transfer representing computational state (REST[1],
> ala Roy).
> But WebDA does. Its methods are completely architecturally aligned with REST
> (unlike arbitrary interface-level API RPC cruft, like an application method).
> Having said that, I don't see a great need for WebDA because, IMHO, the cost
> of deployment is much greater than the benefit; you can do most of the good
> stuff with just HTTP 1.1.
>
WebDAV talks about *application level* abstractions. IMO, if you buy HTTP as *the
new transport,* then it doesn't make sense for HTTP to gain application level
semantics. Besides, it's simpler and more useful for everyone if it doesn't. I
myself plan to basically ignore DAV entirely. ;-)
> Whoa, "RPC" has no place in that paragraph. Hopefully you meant
> "message passing".
Point, but nitty semantics. Yes, I'm equating message passing and RPC. They both
require naming, end-point routing, marshalling, etc.
Thanks for the discussion and pointers!
jb
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 18:47:33 PST