[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Generality of HTTP

• To: xml-dev@l...
• Subject: Re: Generality of HTTP
• From: Paul Prescod <paul@p...>
• Date: Mon, 21 Jan 2002 21:31:22 -0800
• References: <69B15B675E99D411A4110008C786DA23020CC939@e...>

Miles Sabin wrote:
> 
>....
> >
> > How does any of this violate or otherwise work against HTTP
> > principles?
> 
> It doesn't, but it pretty clearly goes beyond HTTP.

I guess we're in danger of going around in semantic circles. Is there
any practical problem with using HTTP in this way? If you suggest any
other protocol I'll point out the practical problems with it in a web
context.

> ...
> > Is retry really even a protocol issue or just a software issue? Does
> > SMTP have a better solution?
> 
> HTTP has inherently ordered, nearly synchronous, RPC semantics.
> There's nothing to prevent you building fully asynchronous, one way,
> multicast or out of order communication models on top of it. But
> those models _are_ built on _top_ of it.
> 
> Calling that an application or calling it a layered protocol is to a
> certain extent a matter of taste, but not entirely ... 

You misunderstood me. I didn't ask whether retry is a protocol issue or
an application issue. I asked whether it is a protocol issue or a
software (implementation of protocol) issue? Couldn't I write an HTTP
client that DOES retry and an SMTP implementation that does NOT do
retry? Retry on GETs and PUTs are safe  because both are idempotent. It
takes a wee bit more effort on the part of the application creator to
make a re-tryable POST service.

 Paul Prescod

• Follow-Ups:
  • RE: Generality of HTTP
    • From: "Miles Sabin" <msabin@i...>

• References:
  • RE: Generality of HTTP
    • From: "Miles Sabin" <msabin@i...>

• Prev by Date: Re: Generality of HTTP
• Next by Date: RE: Generality of HTTP
• Previous by thread: RE: Generality of HTTP
• Next by thread: RE: Generality of HTTP
• Index(es):
  • Date
  • Thread