W3C home > Mailing lists > Public > www-ws-arch@w3.org > January 2003

Re: Dynamic invocation vs. late/dynamic binding

From: Mark Baker <distobj@acm.org>
Date: Tue, 7 Jan 2003 23:26:03 -0500
To: Sanjiva Weerawarana <sanjiva@watson.ibm.com>
Cc: www-ws-arch@w3.org
Message-ID: <20030107232603.I29146@www.markbaker.ca>

Hey again,

On Wed, Jan 08, 2003 at 09:14:02AM +0600, Sanjiva Weerawarana wrote:
> I'm afraid you've lost me somewhere. I don't see how a *non-human*
> (or should I say inhuman? ;-)) REST automaton can just do a GET 
> on an opaque URL and magically understand the data

I think my response to Miles answered these questions.

We're getting away from your earlier concrete point about not
being able to interact with squares and circles via a common
interface though.  I would like to talk about that, and
specifically what you meant by "meaningful interaction".
Why can't a client written to interact with shapes, access
and manipulate squares, if the shape abstraction is designed

> while an automaton
> driving a non-REST POST with the URL contained inside the SOAP
> envelope cannot. 

Again, the answer is within the other thread.

> It seems to me that we're back to the "REST can, but others can't"
> position which I cannot accept.

Well, while I think REST is special, it's not *that* special.  8-)
There are other architectural styles which "can" too.  *Every*
single successful architectural style on the Internet, whose
interactions cross trust boundaries, can.  That's what an application
protocol enables, because it defines that abstraction.

For example, IMAP, and whatever it's architectural style is called. 8-)
It defines a network interface to mail servers.  It's the only
abstraction that an IMAP client needs to deal with in order to interact
with a variety of third party mail servers who have exposed their
server's functionality and data via the IMAP protocol.

Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis
Received on Tuesday, 7 January 2003 23:25:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:02 UTC