From: Kragen Sitaker (kragen@pobox.com)
Date: Wed Mar 15 2000 - 18:26:01 PST
[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. :)
> >With HTTP, you've got a generic request-response system --- i.e., message
> >passing. Message passing is provably sufficient for anything computable.
>
> So are smoke signals. 8-)
You both have a point. As soon as Jeff starts doing his computing on a
platform that uses XML-RPC instead of the X protocol to transmit
graphics updates to the screen, I'll change my mind about Mark having a
point. :)
> >But
> >wait, there's more! With "servers" on both ends, you can have callbacks,
> so you
> >can do asynchronous stuff. With XML and something like XML-RPC, you've got a
> >typed RPC mechanism and on-the-wire object format. You want objects? Fine,
> >build an interface repository and reflection on top of that.
>
> 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?
It does sort of defeat the point; aside from the dubious benefit of
surreptitiously tunneling through firewalls, XML-RPC could just as well
be implemented over plain TCP as over HTTP. I'm not really sure why
Dave Winer chose to use HTTP as the canonical substrate.
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,
and reinventing it to be slightly better would provide no payoff for
this vast majority.
It is probably not well suited for specialized tasks, like that involve
very high volumes of requests (X can theoretically handle something
like 4 million requests per second on a uniprocessor), require very low
latencies (MPI over VIA over Fast Ethernet has something like 80
microseconds latency), operate within very tight resource constraints
(I'm sure it'll take at least a few thousand instructions to implement
XML-RPC, which is bad if you only have space for 2048 instructions on
the microcontroller controlling your robot), etc.
> >This kind of stuff should live above the wire, indeed, above HTTP. If all
> >distributed systems can be implemented in terms of RPC, and HTTP provides a
> >*standard* and rather friendly RPC just with GET, and XML provides the
> >marshalling format, then why re-invent the wheel?
>
> Whoa, "RPC" has no place in that paragraph. Hopefully you meant
> "message passing".
You could think of GET as being an RPC, albeit an RPC that has certain
caching (and thus idempotence) semantics. 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.
-- <kragen@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/> The Internet stock bubble didn't burst on 1999-11-08. Hurrah! <URL:http://www.pobox.com/~kragen/bubble.html> The power didn't go out on 2000-01-01 either. :)
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 18:26:20 PST