Re: Feedback about the content processing framework

----- Original Message -----
From: "Alex Rousskov" <rousskov@measurement-factory.com>
To: "Robert Collins" <robert.collins@itdomain.com.au>
Cc: "Squid Dev" <squid-dev@squid-cache.org>
Sent: Thursday, February 01, 2001 7:30 AM
Subject: Re: Feedback about the content processing framework

> On Thu, 1 Feb 2001, Robert Collins wrote:
>
> > hmm, all three routines will have the same layout:
> > perform data check/alteration
> > call next fiter
>
> At least 30% of all Squid functions probably have the same layout :)

Yes:-] It's where I go the thought from - the te code was sticking out like a sore thumb

> > splitting the flow into three chains called from the initiaing
> > squid function means that a filter cannot arbitrarily decide to
> > abort the transfer as easily: the abort would have to flow through
> > the chain, then the End chain would have to be called. I think
> > that's a down side.
>
> I am not sure what you mean here. If I were to implement the original
> API, I would still split the processing into three internal functions,
> if I could:

Ah. Crossed wires. Yes I agree that a particular filter should break it's processing into large chunks (header/body/termination) to
ease this. In fact a filter can replace itself in the chain after it's seen the headers, and actually have two discrete functions
that way.

>
> > Also coredumping analysis of reentrant funcitons is never going to
> > be that easy - and with instances these are reentrant.
>
> I did not say "easy", I said "easier". :)

:]
Received on Wed Jan 31 2001 - 13:35:21 MST