Re: The Two Way Web

Mark Baker <mark.baker@Canada.Sun.COM> writes:

> Ken MacLeod wrote:
> > XML messaging does what HTTP does, just differently because no one
> > wants to mess with HTTP's installed base (i.e. if it doesn't use only
> > GET/PUT/POST it probably ain't gonna happen).  One of the most common
> > ways to implement XML messaging is to actually tunnel those messages
> > on top of HTTP's POST (and less often, GET and PUT).
> 
> Sure.  I think POST makes most sense for messaging, since its
> semantics are to insert a document into a container, like a message
> into a channel.

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?]

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).

> > XML messaging often suggests many different types of methods than
> > GET/PUT/POST.
> 
> And HTTP supports extension methods for that reason.  But what
> methods did you have in mind?  Are you sure they're necessary?
> The standard HTTP methods are pretty powerful. (see below)

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!  ;-)

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 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.

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.

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.

> > > > Now to DWChat. getMessages() and postMessage() are both
> > > > "actions" that do something much different than simply "get" a
> > > > value or offer data to a function (POST).
> > > >
> > > > In scenario one from above, that would be:
> > > >
> > > >   DWChat:getMessages http://mysite.org/chat_channel_1 HTTP/1.1
> > > >   DWChat:postMessage http://mysite.org/chat_channel_1 HTTP/1.1
> > > >
> > > > Note that some URL munging could be applied here to achieve
> > > > the same effect with GET/POST, but I don't think that scales
> > > > well.
> > >
> > > URL munging to avoid caching?
> > 
> > URL munging as a different technique of passing what "method"
> > (action) I want the server to perform.  It's a hack that could be
> > worse than tunneling.
> 
> 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().

  <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.  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.

  -- Ken

Received on Saturday, 11 March 2000 10:46:04 UTC