RE: Why GET is an application semantic

Indeed these days tunneling really means smuggling :-)

-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org] On
Behalf Of Joseph Hui
Sent: Wednesday, June 19, 2002 11:50 AM
To: Mark Baker
Cc: www-ws-arch@w3.org
Subject: RE: Why GET is an application semantic



> From: Mark Baker [mailto:distobj@acm.org]
> Sent: Tuesday, June 18, 2002 9:07 PM
> To: Joseph Hui
> Cc: www-ws-arch@w3.org
> Subject: Re: Why GET is an application semantic
> 
> Hi Joe,
> 
> On Tue, Jun 18, 2002 at 07:52:28PM -0700, Joseph Hui wrote:
> > [GET] http://nasdaq.org/get?what=quotes&type=stock&symbol=sunw
> 
> What does "get" help identify in that URI?

The implementation-specific "get" function provided by nasdaq.org, which
may choose to implement it through a CGI script or whatever. 
Note that nasdaq.org may opt for several GET implementations, allowing
for method overloading at run time. How's that for polymorphism in HTTP?
;-)

> What if I want to
> invoke PUT on that URI, do I still need the "get"?

No, you'd use the "put" function as in:

   http://nasdaq.org/put?what=quotes&type=stock&symbol=sunw&price=6

> URIs and HTTP work together when HTTP provides the methods, and URIs 
> provide the identifying information.  As soon as you try and make one 
> do the job of the other, you run into all sorts of problems.
> 
> A URI is like an object reference.  It's just a pointer.
> 
> > I tend to read the HTTP GET as a protocol-intrinsic method upon
> > which application semantics can be freely built (by app developers).
> > Am I "web-arch'ly incorrect" in this regard?
> 
> 'fraid so. 8-(
> 
> Would you consider building application semantics on top of 
> getStockQuote()?  If so, what would that look like?  I've used this 
> example before, to show how odd that would look;

The getStockQuote() method is not protocol-intrinsic.  
It didn't come with the HTTP 1.1 spec, for instance.

> String weather = getStockQuote( "getWeather( 'Ottawa' )" );
> 
> That's called tunneling.

Or overloading, perhaps?  The first thing comes to mind when "tunneling"
is mentioned tends to be "blind relay," e.g. a transparent proxy, when
HTTP is spoken of.  That's IMHO at least the case among CDN (Content
Delivery Network) jocks, in the spirit of HTTP 1.0 and 1.1.

BTW, as far back as I can recall, the "tunneling" term was initially
coined by networking folks to mean transporting network-level packets of
one protocol as the data payload of another protocol (at pretty much the
same layer in an OSI stack), e.g. an IP tunnel in X.25.  These days, I
find it necessary to check the context of discussion more carefully in
order not to misinterpret the writer or speaker's true intent for
"tunneling" as a term. Anyway, tunneling is what tunneling is, or may
be. As long as we understand each other, what's big deal right? :-)

Cheers,

Joe Hui
Exodus, a Cable & Wireless service
=============================================

> 
> MB
> --
> Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
> Ottawa, Ontario, CANADA.               distobj@acm.org
> http://www.markbaker.ca        http://www.idokorro.com
>

Received on Wednesday, 19 June 2002 15:03:27 UTC