Hi,
IMO, the primary reason to use HTTP as OCP transport would be
"compatibility" with ICAP. I wonder if ICAP proponents would consider
it possible for ICAP/2.0 or ICAP-NG to use something other than HTTP
as transport? Or will selection of other transports kill the
opportunity to merge ICAP/2.0 and OCP?
What do you think? I am especially interested in comments from Martin
Stecher and anybody else with first-hand ICAP experience.
I am just returning from an easter holiday, sorry for the delay.
I fully agree to what Hilarie and John explained regarding the ICAP history and
the motivation to have it in a HTTP-like style.
ICAP developers from the first hours that migrated from ICAP/0.9 and ICAP/0.95
to ICAP/1.0 already experienced the development from a pure HTTP implementation
to a standalone protocol (which is still very much like HTTP though).
It is definetly a plus that ICAP developers can benefit from their HTTP
protocol experience and probably have already some source code around that can
be reused when implementing ICAP.
On the other hand ICAP/1.0 is different from HTTP and that may require changes
to existing HTTP handling code which may introduce new problems as well, e.g.
the existence of two zero-end-chunks within one message.
If you look in the ICAP implementation within the Squid project you will also
find that reusing the HTTP code for ICAP can make things hardly readable.
Getting this together I believe that ICAP/2.0 can have a different transport
than HTTP. Creating a new ICAP version without touching the transport layer
seems nearly impossible to me.
Picking a fully binary protocol would be a too big difference though. I think
ICAP TNG should still have some text elements and some ICAP-known syntax
elements like icap-URIs.
Regards
Martin