[
Lists Home |
Date Index |
Thread Index
]
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
|
