RE: SACRED over HTTP (was: RE: sasl in beep or payload)

Keith,

Thank you for the explanation.

It is clear that caching would have to be disabled if SACRED were to run
over HTTP (adding the required cache control headers doesn't seem to be too
much extra work) and given the fact that the current proposals are that the
protocol will not support pipelining then I am still not sure why the cache
and ordering issues you raise would be such show stoppers.

I may be running the risk of sounding like a do-everything-over-HTTP
advocate (which I am not) by pursuing this thread but I think it is very
important to get as good an understanding of as many of the issues involved
as possible in order to make informed decisions.

>
> each HTTP transaction is separate.  there is no assurance that multiple
> HTTP transactions for the same request-URI share the same TCP connection
> or even that they get sent to the same host.  HTTP caches may route them
> differently.
>
> The other reason that it is not suitable is that with HTTP you have to
> do extra work - by adding headers - to discourage caches from interfering
> with your payload.  the existing infrastructure for HTTP doesn't help
you;
> rather, it gets in your way.
> TCP gives you a bidirectional sequence of octets, with order preserved
> (without doing stop-and-wait), duplicates suppressed, and clean
> termination.
>
> HTTP gives you the ability to make requests of a URI, with no assurance
> that order will be preserved unless you do stop-and-wait, no duplicate
> suppression, and no assurance of clean termination.  HTTP has more
overhead
> than TCP and is a poorer match for SACRED than TCP.  And unlike IP
routers,
> HTTP intermediaries are likely to modify the payload in undesirable ways.
>
> Keith
>