Re: Generality of HTTP
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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format