Re: The Two Way Web

>Mark Baker <mark.baker@Canada.Sun.COM> writes:
>Ah.  I'm miscommunicating.  Darn those overloaded terms.  And to make
>it worse, _I'm_ not clear yet on why or how some XML folks distinguish
>"XML messaging" from remote methods (RPC, Distributed Objects, ORBs),
>I just know that "they" want to make a [some?] distinction.  [Anybody
>willing to cough up a definition of "XML messaging" that is distinct
>from RPC?]

I cowrote a paper that talks a lot about this a while back.  Read
section 7 (7.2 if you're in a hurry);

http://www.interlog.com/~resnick/res-baker.html

>
>In any case, I _am_ discussing practical use of methods beyond GET,
>PUT, and POST.  In the RPC/DO/ORB case, I'm talking about the method
>names used in applications (IDLs).

I understand.  But I would argue that arbitrary RPC methods names have
no place being methods over HTTP.  It's an entirely different problem.

>If they're not necessary then we have an entire industry of software
>developers "doing it wrong" writing software that doesn't use only
>GET, PUT, and POST methods on objects!  ;-)

That's exactly right.  I was one of those lost souls for a number
of years.  Luckily, I've repented. 8-)

RPC does have its place of course, I don't want to totally shoot it
down.  But IMHO, its sole use is when you control both client and
server.

>GET and PUT make a lot of sense at the object and member field
>accessor level (for Java folks: anywhere you'd use get*/set* methods)
>but it doesn't make sense for all the other methods that applications
>use.  A single POST operation would be _way_ too overloaded for
>implementing a wide variety of methods.

I disagree.  GET and PUT are document/message granularity, not
method/attribute granularity.  I would never use HTTP in that
manner, since the number of network round trips would be
prohibitive.  Ironically, this is just what would happen if a
local API with lots of get/sets (which makes good sense locally)
were distributed as-is over the network.

>> > I refer to a third scenario in this message above, that of tunneling a
>> > messaging protocol through HTTP.  That's simply a hack, a very, very
>> > common hack, but a hack none the less.
>> 
>> Why would you need to tunnel a message protocol over HTTP?  Why
>> not just send the XML directly over HTTP?
>
>When referring to [at least] the RPC/DO/ORB case, it's clear that the
>envelop+body of the existing protocols are, themselves, complete
>protocols.  They can stand on top of TCP alone, without HTTP [this is
>why users request the specs be modularized to reflect this].  Because
>of that I find it makes more sense to say that these protocols are
>"tunneled" over HTTP 1.1 than to say that they use or layer over HTTP
>1.1.

Yes, that's my understanding of tunnelling.  I just don't
understand why you need a protocol on top of HTTP to do messaging.
HTTP does that just fine by itself.

>But that's also the distinguishing characteristic I'm making between
>my scenario one (extensible HTTP 1.1 methods, the HTTP header is the
>RPC/DO/ORB envelope and the HTTP body is the RPC/DO/ORB payload) and
>scenario two (a new spec for envelope+body that is its own complete
>serialization, different from [but obviously similar to] HTTP).
>
>When I implied "let's do both" in an earlier message, I see how we can
>use HTTP 1.1 directly (today, and for a long time), but I would also
>_still_ like to see a new envelope+body serialization spec.  The
>biggest reason for a standard serialization is that it can be swapped
>out with a different, differently optimized, serialization.

But it seems to me that you want this spec because you still want to
carry RPCs over HTTP.  Right?

>If you look at it this way, you can see how HTTP 1.1 itself specifices
>both a serialization (RFC822-like plain text headers) and methods
>(GET, PUT, POST).  As another example, the HTTP-NG effort was looking
>at defining a new serialization (IDL-based binary) with the same HTTP
>methods.

I never understood what HTTP-NG was trying to achieve (despite
reading all their early drafts).  Luckily, it's far from a going
concern.  8-)

>> Inserting a chat message into a chat channel is perfectly
>> aligned with HTTP POST semantics.
>
>Miscommunication again, I shouldn't have used an example application
>that uses the term "message" in its API.  A better example would be
>the Dining Philosphers problem, and the API call would be
>aquireFork().

That would be more of a LOCK, ala WebDAV.  But GET plus some
application locking semantics would have sufficed, I would think.

>  <http://cs.millersv.edu/cs380/assignment5.html>
>  <http://www.cs.rpi.edu/~damoum/DiningPhilosophers.html>
>
>> What other action do you need the server to perform?  Can that be
>> represented by posting a different XML document to a sub-URI? eg.
>> 
>> http://mysite.org/chat_channel_1/admin/
>> 
>> The documents posted to that URI would represent different
>> adminstration actions one could take on the channel.
>
>Yes, that's the URL munging that I refer to. 

Except that "admin" isn't a method, it's a container that accepts
documents representing adminstrative commands.  The desired action
to be taken is in the type of the document being transferred.

> As long as we understand
>each other, I'm willing to simply disagree on which approach is
>"better".  I believe unique method names are better suited to APIs
>than unique URLs are.

Yes, we certainly do disagree.  But I'm not finished with my
argument yet, so you're not getting off that easy.  8-)  (instead
of talking about just HTTP though, I'll talk just about the
perils of RPC)

Unique method names *are* better suited to APIs, obviously, since
APIs *are* method sets, nothing more.  But there are other ways to
do distributed communication, and that's what I'm talking about
here; messaging.

The problem with RPC is that it's one layer doing the work of two.
Just developing an on-the-wire protocol that is optimized for speed
and latency for a single application space is tough enough.
Designing an application level API for accessing that protocol is
tricky too, and requires very different skills.  RPC is both.  On
one hand you're trying to build an API that is easy for application
developers to learn and use, but on the other you're trying to
optimize it for the network.  If you're only doing one of the two
your system will either be horribly slow, or difficult to use.

That attribute get/set example above should hopefully demonstrate
this quite well.  Ideally, you'd like to be able to maintain
that API for the developer, but have a protocol underneath that
doesn't require a network round trip for each method invocation.
The only way to do this is to layer the problem.  RPC doesn't
allow for layering.

So, you're left with designing your own protocol if you've really
got a problem that can't reasonably be broken down to documents.
Or if you can break it down, use HTTP.  But please, no RPC.

MB

Received on Saturday, 11 March 2000 12:20:50 UTC