Re: status of internal redirectors?

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       mnot@yahoo-inc.com