I was talking about the rewriters / redirector, actually.
Given that the helper interface is easy to understand and widely used,
whereas eCAP essentially requires writing a squid plug-in, I can't
agree, Alex. This isn't a big change at all, and the jump from a
rewriter to eCAP is a big one.
Note that I'm *not* talking about using helpers to rewrite headers or
similar; all I want to be able to do is to adjust what the input to
the helper is, so that it can make rewrite decisions on things other
than client_ip, url, method. E.g., rewriting based upon a cookie.
Cheers,
On 09/05/2008, at 8:01 AM, Alex Rousskov wrote:
On Thu, 2008-05-08 at 23:19 +0200, Henrik Nordstrom wrote:
On tor, 2008-05-08 at 08:35 -0600, Alex Rousskov wrote:
I am not sure this is the same topic, but I have already raised
doubts
(on the wiki and in the bug report) that we should extend the
Squid-specific helper interface significantly beyond its current
relatively simple state. I still believe it is worth discussing
whether
more complex uses should be routed through ICAP or eCAP instead of
slowly inventing yet another complicated and poorly maintained
traffic
adaptation interface.
I think Mark is talking about the store url rewriter. It's a cache
maintenance function, not really modifying the request/response in
any
manner, and I don't see how to fit that in ICAP or even the goals of
eCAP.
But it's possible eCAP may grow in future to include such things..
Agreed on all counts: store rewriting does not fit ICAP or current
eCAP
scope well, but eCAP scope may change. My comment still applies, I
think. ICAP and especially eCAP do not really care what the vectoring
point is. They just "rewrite" messages that we feed them with. The
purpose of that rewrite (in a broad sense) can be a cached URL
maintenance function, for example.
Alex.
--
Mark Nottingham [EMAIL PROTECTED]
