From: Mark Baker (distobj@acm.org)
Date: Wed Mar 15 2000 - 23:25:07 PST
There's only so many hours in a day, so I'm going to trim this down
substantially.
At 11:07 PM 3/15/00 -0600, Jeff Bone wrote:
>sets up with the original design of HTTP? What's wrong with something like
>
> http://foo.host.com/class/object/method?arg=blah
>
>OR, if you like this better
>
> http://foo.host.com/class/object with <methodCall> ... in body?
>> You don't *need* RPC.
>
>Oh, get off the name semantics. I'm talking RPC in some very abstract
manner ---
>RPC as an *application* of HTTP. And yes, I very much believe I *do* need
to be
>able to invoke code somewhere else to do something besides spit me back a
piece of
>static HTML. I don't want to just say "give me the state of X." I want
--- need
>--- to parameterize requests. Query strings, POST bodies, whatever.
[ pay attention to this one! 8-) ]
You don't *NEED* to do any such thing!!! It's all freaking equivalent!!
The only question is whether it's *efficient* for a broad problem domain.
>I am happy with HTTP --- as is, pre-DAV. Let's see if I can frame the
argument.
>HTTP is a combination of two things: a wireline protocol for "requesting
certain
>resources" combined with a global, loosely-coupled naming scheme based on
DNS.
>Okay, fine, that lets me identify my server objects and request that they
return
>me *something.*
A representation of their state.
>I'm quite happy with the response, if it's some MIME body --- oh,
>say, XML data. Still, I need to parameterize those requests --- and the
WHOLE WEB
>seems to need that as well.
GET is the request. What do you need to parameterize?
>> 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?
>
>Aw, geez. How does this break the Web's architecture? Caching? Bullshit.
>Surely it is --- and should be --- up to a given resource to define caching
>policies. Do I cache method results? No, of course not. But that's already
>accomodated, without much pain or controversy, in the existing architecture.
You're not caching that "document" because it doesn't make sense to, not
because the content itself is updated very frequently. *BIG* difference.
>Ah, but my point --- insisting upon HTTP as being about a particular
domain of
>resources --- call them "documents" --- is an academic viewpoint almost
completely
>disjoint from the reality of today's Web.
Not at all. The *VAST* majority of web applications out there are Good.
Off the top of my head, the only bad ones are those than tunnel other
protocols through POST; XML-RPC/SOAP, RealAudio/Video, etc..
>So, we have three camps AFAICT:
>
>Mark: HTTP-believer, hypertext purist
>Adam: HTTP-nonbeliever, protocol-per-app enthusiast
>Jeff: HTTP-abuser, protocol antagonist, "I just want to build apps"
>
>Oh, well. Anyone want to make an idea futures claim on which of these
will turn
>out to be the winning position in the long term?
We've been at it in a big way for 5+ years, and there's a clear winner
right now. I'll let my bet ride.
MB
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 23:41:04 PST