Re: FW: LC Comments: Web Method Feature

Amelia A Lewis wrote:
> 
>...
> > The only reason there even existed a concept of an FTP to SMTP gateway
> > fifteen years ago was because FTP and SMTP used different addressing
> > models and different method names/semantics. If those were unified into
> Horsefeathers.
> 
> FTP and SMTP have dramatically different semantics: synchronous versus
> asynchronous, "push" versus "pull" (much as I dislike that distinction).

You do not need separate wire protocols to get synchronous versus
asychnronous behaviours or push versus pull. If you did, the *web could
not exist* because people use it every day in synchronous and
asynchronous ways, push ways and pull ways. 

It seems to me indisputable that if FTP and SMTP were the same protocol,
there would be no need for a gateway. It is also *demonstrable* that
(today) they could be the same protocol with no loss of expressiveness
(quite the opposite, the unification would enrich both).

>...
> Adding URIs would have done zero good, at that point.  If you can't use
> TCP/IP, or don't have an eight-bit clean connection, a library's worth
> of URIs don't solve any problems.

Okay, fair enough, there were other technical impediments at the time.
That is not true today.

> Incidentally, URIs also typically suggest a strongly client-server
> model, a pull model, and synchronous interactions.  All of those may be
> good reasons to speculate on how to extend URIs, or what good addressing
> semantics are for asynchronous, or push, or strongly peer-to-peer
> models.

First, URIs are as useful for push as for pull. Second, client-server is
increasingly the description of a transaction, not a topology. Every day
people use HTTP in widely-deployed, popular, peer-to-peer programs.
First you're the server. Then I am. Similarly, SMTP->Web gateways
demonstrate that there is nothing intrinsically synchronous about URIs.
So I don't follow what extensions URIs would need, or what you mean by
"good addressing semantics." People even use HTTP ascynchronously every
day 

> > "ftp client" would be just a different user interface for the shared
> > protocol. Therefore, our views are diametrically opposed to those of the
> > people that Ameilia quotes above. We are not trying to stop people from
> > solving problems. We are trying to encourage them to solve them *in the
> > most interoperable way*.
> 
> I remain unconvinced.  I'm not convinced, from the above, that the folks
> currently pushing REST so hard are even aware of the design parameters
> and history of the rest of the stack (discussion of the OSI model, in
> the context of the discussion of protocol design for the TCP/IP stack,
> makes me extremely suspicious).

OSI terminology is pervasive in the networking industry. It is still the
default reference stack. I do not claim to know all of the history of
the Internet. I do know that the assumptions of thirty years ago should
not go unchallenged into the next millenium.
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/

Received on Tuesday, 9 July 2002 10:30:59 UTC