[
Lists Home |
Date Index |
Thread Index
]
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@interx.com http://www.interx.com/
|
