Re: status of internal redirectors?

On Fri, 2008-05-09 at 14:44 +1000, Mark Nottingham wrote:
> Sure, great. In squid3, it sounds like an eCAP module is the
> appropriate way to implement this; at which point you'll still need to
> implement the helper protocol, and then we'll be having the same
> conversation.

Yes, but that conversation will not be on squid-dev because eCAP modules
will not affect Squid code. That's one of the big motivations behind the
eCAP project -- keep the myriad of useful-for-some customizations away
from Squid core so that the core can be better optimized, cleaned,
maintained, etc. The alternative is the dumping ground approach we are
enjoying right now, with every little new customization not worth (and
nearly impossible) fighting against.

Cheers,

Alex.

> In the meantime, if the internal rewrite stuff is going to go into a
> 2.7 release, it seems like squid can be made to address a number of
> (but not all) use cases that real people are using HTTP intermediaries
> for today, with very little code change, with the side effect of
> making squid simpler to use (because there won't be multiple ways to
> set up a helper).
>
> I'll let your fallacy stand on its own (or not)... :)
>
>
>
> On 09/05/2008, at 2:26 PM, Alex Rousskov wrote:
>
> > On Fri, 2008-05-09 at 10:09 +1000, Mark Nottingham wrote:
> >> 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.
> >
> > Not if there is an eCAP module that supports the helper interface.
> >
> >> 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.
> >
> > Yes, I am using the slippery slope argument. The person before you
> > asked
> > for Squid port value. You ask for headers. The next person asks for
> > the
> > first 10 bytes of the body (to determine the true message type), and
> > the
> > third person complains that the redirector failures are not bypassed
> > or
> > that the redirectors are not chained.
> >
> > Alex.
> >
> >
> >> 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
> >>
> >
>
> --
> Mark Nottingham mnot@yahoo-inc.com
>
Received on Fri May 09 2008 - 05:07:10 MDT