RE: OPES protocol, pre-draft

On Fri, 21 Feb 2003, Martin Stecher wrote:

> ICAP/1.0 is already pipelined, I think. Messages are sent in chunked
> transfer encoding. ICAP clients send chunk N before waiting for the
> modified chunk N-1 to return.
You are right, of course. I should have mentioned that ICAP does use
pipelining. IIRC, ICAP pipes start only after message headers and do
not allow any non-data messages to be present in-between (which forces
ICAP to use a chunk-extension hack to indicate end-of-data).

Another ICAP pipes disadvantage is that they cannot eliminate
callout-to-processor data flow when the callout processor did not
modify the data. The proposed protocol allows for this important
common-case optimization using "data-asis" messages.

Finally, ICAP pipes place ICAP connections in direct dependence on
HTTP connections. If I have to process 5 HTTP messages _concurrently_,
I have to open 5 ICAP connections. With the proposed approach, I can
use 1, 2, 3, 4, or 5 OPES connections. This allows for possibly
important performance optimizations on high-traffic servers.

These limitations of ICAP model apparently come from it being an
extension to HTTP (rather than being implemented on top of HTTP).
OPES pipes are not an optimization add-on but a design feature.

It remains to be seen if the proposed protocol is so much better that
it actually makes sense to phase out a working/deployed ICAP protocol.

Alex.