RE: Generality of HTTP
Paul Prescod wrote, > Miles Sabin wrote: > > Not quite. Suppose the response endpoint is disconnected when the > > responder attempts to call back. Yes, the responder can retry > > later, or maybe consult some registry or other for an alternative > > target URI. > > How does any of this violate or otherwise work against HTTP > principles? It doesn't, but it pretty clearly goes beyond HTTP. > > But look what we're doing here: we're layering another protocol on > > top of HTTP, a protocol which doesn't match HTTPs semantics very > > well. > > Doesn't match how? What are HTTP's semantics? I'm starting to > understand them (years after I first worked with HTTP) and the more > I do, the more general they seem. > > 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 ... where the interactions are general (ie. where it's natural to consider those interactions being implemented on top of a variety of lower level protocols, rather than being strictly context specific) then it makes more sense to think in layered protocol terms rather than application terms. That, for example, is why HTTP is a protocol rather than a TCP application. Cheers, Miles -- Miles Sabin InterX Internet Systems Architect 27 Great West Road +44 (0)20 8817 4030 Middx, TW8 9AS, UK msabin@i... http://www.interx.com/
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