From: Jeff Bone (jbone@jump.net)
Date: Wed Mar 15 2000 - 21:07:26 PST
Mark Baker wrote:
> Uh oh, I think Dave's probably had enough of me recently. 8-)
>
Dave, are you being mean again?
;-)
> 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.
No, no, that's just the opposite of my point! Forget about the original semantics
of HTTP as "document transfer only" --- it's perfectly clear we've gone way beyond
that. GET/POST *are* generic invocation primitives already. The main question is
this: do we extend and muck up the semantics via additional methods, or do we
layer RPC semantics on top of these invocation primitives in a standard way,
albeit at a higher level ala XML-RPC? In my mind, the latter is infinitely
preferable.
At least we agree that adding methods to HTTP --- i.e., to HTTP the protocol,
rather than something over HTTP --- is undesirable.
I don't get your "legacy of RPC" statement, but I suspect you are misunderstanding
what I mean by RPC.
> >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.
Granted. The purpose of my reductio was to point out that the URL namespace
itself in the context of a GET could be (albeit ludicrously) overloaded to
whatever extent you want. POST is much preferred.
> 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.
Several cool points. POST as generative communication put() --- yes, nice idea.
But then, where's the GET? If you want to put generative semantics into HTTP and
you want GET/POST symmetry, you still end up overloading the URL namespace with,
in the get() case, the tuple template to match. Which I think is one of the
things you're arguing against, here.
The generative communication semantics --- particularly when extended by leasing,
as in JavaSpaces --- are really quite rich. It turns out that message passing and
generative communcation are in some sense equally complete --- you can implement
either in terms of the other --- but not expressively equivalent. At a practical
level, though, the generative semantics are more abstract and lead to a richer
class of solutions.
The leasing abstraction introduced in JavaSpaces clears away one of the primary
problems with Linda --- persistent shared garbage. Some extensions to the
generative model that I've been toying around with for some time include the
following: antileasing (you can only remove this tuple from the tuple space for X
amount of time) and strict-ordering of tuples. (I.e., for a given template, the
tuple space is a sort of FIFO or Queue(a) where Queue is a parameterized type on
the type a of a tuple template.)
One of my pet projects that I've never gotten around to past whiteboard
discussions is to implement a Linda-like system over XML-RPC. It should be
incredibly easy --- just a small matter of programming. ;-)
> 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.
Oh, some on, you're not *really* going to make that argument, are you? GET maybe
meant that back when the only browser out there was that NeXT doohickey. That
whole purist notion has been out the window since early last decade. Let's be
pragmatic. So "GET" isn't the right word. Fine --- rename it. Explain cgi-bin
in the context of your semantic constraints. Are you against dynamic content in
general? Or just the naming scheme that emerges, and the cognitive dissonance it
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?
If the only answer to that question is "GET means GET, dammit" --- well, that's
not a very compelling argument.
> 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.
Fine, tell that to the corporate developers who want to diffuse their innovations
through corporate firewalls but have a 2-3 year lead time --- and lots of dollars
spent --- lobbying firewall vendors to open up port XXX for this new-fangled
innovation, and lobbying the IETF for standardization of some particular thing.
> 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. I don't know
if you've noticed, but there're a WHOLE LOT of things out there on the Web that
exploit this ability. ;-) If you want me to strictly interpret your argument,
then I have to assume you're against dynamic content generation and Web-mediated
interactive applications in general.
> 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.
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.* 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. I don't see how that's a "bastardized" application of
HTTP. And I don't see why it's not perfectly fine to consider that an RPC,
either. I see no conflict here. I think you must either be hung up on name
semantics or caught in some kind of cultural / mindset trap.
> 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.
> It talks about resource abstractions. It's hard to call those "application
> level" when HTTP is also concerned with them.
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.
> 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.
You caught me. ;-) I was just reinforcing the point.
> 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".
I don't think these are misunderstandings at all. I completely understand your
point of view --- and you're certainly not the only one to espouse it. I just
don't agree with it. As a practical matter, a combination of factors inhibit the
creation of new application protocols. These include administrative overhead,
security domains, IETF and corporate politics, IETF latency, and so on. The Web
itself is a clear example of how "the street finds its own uses for things."
It's funny that this whole argument is an example of how the needs and innovative
speed of corporations have surpassed the previous rough-and-tumble, can-do anarchy
of the IETF. HTTP has become an end-run around those things, a way for innovators
to supply cool new functionality to users without the time, cost, and headaches of
dealing with all of the above. And the Web purists are disappointed that this
thing has so much versatility? Is protocol design so much fun that it's worth
holding up the broad rollout and adoption of new apps for *years?*
Not in my book.
OTOH, if we need all of these new application-level features, does that put the
problem space in the protocol design arena? Not necessarily. A single RPC-like
request-response protocol does the trick, booting the rest of the play strictly
into the application arena and away from protocol. (And we've got one of those:
it's called HTTP, and it really doesn't need any more methods beyond GET, POST,
and maybe --- *MAYBE* --- PUT.) Are the protocol purists disappointed that they
don't get a crack at all of that fun application stuff? Too fucking bad.
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?
jb
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:13:36 PST