On Fri, 21 Feb 2003, Martin Stecher wrote:
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.
ICAP's 204 response is something like this, isn't it? Similar to
your proposal, the ICAP client needs to advertise that it keeps a
copy of the data (by adding the Allow: 204 ICAP header) and the ICAP
server can then respond with "ICAP/1.0 204 Not modified" not only
after the preview but after it has seen more or all of the HTTP
data.
Yes, 204 Not modified works similarly but can only be applied to
unmodified message tails (including entire messages) whether OPES
"asis" mechanism aplies to individual data chunks in the pipeline. 204
Not modified is a one-time all-or-nothing decision. Same idea (asis
feature was inspired by ICAP of course), different scope. Asis feature
can be used to reduce data transfer from callout server to processor
to the necessary minimum even if callout server modifies the last
chunk of the message.
So, I do not see any argument why we cannot create a next generation
protocol that becomes at least as successful as ICAP/1.0. Yes, it
will take some time and it has to be much better. But this is the
fun part, isn't it?
Exactly.
I like to talk about ICAP TNG ("the next generation" for all
non-Trekkies) as a working title because I think that the protocol's
success can be maximized if it really looks like a successor of
ICAP/1.0 and is maybe even named ICAP/2.0. As far as I see the
current proposal could still work out in this direction (and also in
something very different, I know).
I agree that calling OPES protocol ICAP may help OPES
acceptance/deployment for non-technical reasons. To save time and
flames, I suggest to avoid the naming issue until OPES protocol is
shaped and the consensus is, in fact, that it is better than ICAP/1.0.
Thank you,
Alex.