From: Mark Baker (distobj@acm.org)
Date: Wed Mar 15 2000 - 20:11:35 PST
Uh oh, I think Dave's probably had enough of me recently. 8-)
At 09:26 PM 3/15/00 -0500, Kragen Sitaker wrote:
>[I Cced this to fork@xent.com so Dave Winer can respond to the list if
>he likes. One of the nice things about zero spam protection is that
>anyone can post.]
>
>Mark Baker writes:
>> [Jeff Bone wrote:]
>> >--- in part because of what I saw going on in the IETF --- that a
>> *minimalist*
>> >HTTP, perhaps with just "GET," would be sufficient for anything.
>>
>> How would you ever change anything? I could see GET/POST or GET/PUT, but
>> just GET?
>
>Idempotently. :)
Indoubetably! 8-)
>Still, I'm not sure it matters; XML-RPC is a great protocol, and it
>does a great job at the vast majority of distributed computing tasks,
It's pretty darned good if you start with the assumption that
RPC itself is good. As you might have guessed though, I don't.
>and reinventing it to be slightly better would provide no payoff for
>this vast majority.
>
>You could think of GET as being an RPC, albeit an RPC that has certain
>caching (and thus idempotence) semantics.
Yah, I've heard that argument before. The main problem with that mental
model is that it encourages one to think that it's perfectly natural to
just add other methods alongside GET that have nothing to do with document
transfer - basically using HTTP as a transport for method invocation.
That's the legacy of RPC, unfortunately.
>POST is probably closer to
>being a real RPC: the name of the routine you're calling is the
>local-part of the URL, the parameters are the POSTed data, and the
>return value is the returned data.
I prefer to think of POST as more a Linda/JavaSpaces "put". ie. inserting
something into a container. There is no "routine", there is only the name
of a container. The action is not explicitly declared; it's implicit in
the reaction of the container to receiving what we shoved into it.
At 08:41 PM 3/15/00 -0600, Jeff wrote:
>
>Imagine that the method isn't called GET, it's called INVOKE.
It's called GET because it *means* GET; grab me a representation of the
state of the resource identified by this URI. INVOKE means nothing. You
can do INVOKE as a method extension, as a new header, or as part of the
payload body (like SOAP and XML-RPC). Any which way you slice it, none of
that means GET and is therefore not compatible with the architecture of the
Web.
> 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.
HTTP is not TCP and should not be used as if it were, even if it saves you
time with marshalling and gets you over firewalls. That's exactly what
you're suggesting.
>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.
You don't *need* RPC. If you're happy with HTTP, why not use it as it was
intended rather than in some bastardized manner? We've already established
that it's all equivalent in computational power.
>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.
But is it worth the cost of breaking the Web's architecture? What exactly
will it mean to cache a method invocation? What will it mean to try to
transcode one?
>WebDAV talks about *application level* abstractions.
It talks about resource abstractions. It's hard to call those "application
level" when HTTP is also concerned with them.
> IMO, if you buy HTTP as *the
>new transport,* then it doesn't make sense for HTTP to gain application level
>semantics.
Tautology. You've defined that HTTP is a transport protocol, so obviously
its not concerned with semantics beyond transport. Luckily for us, HTTP is
more than a transport protocol.
Ya know, I wonder if all these misunderstandings about HTTP could have been
averted if we'd just call it the Hypertext Management Protocol - anything
other than "transfer" which could (and is) so easily misunderstood to be
"transport".
Adam writes;
>Why does everyone think HTTPD is the holy grail?
>Does noone remember it's just a hack of the gopher protocol?
D'em's fightin' words!
MB
-- Friends don't let friends to RPC
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 20:15:13 PST