Re: Feedback about the content processing framework

Could be done :] This is on the edge - design and code the same coin on flipped sides :]

hmm, all three routines will have the same layout:
perform data check/alteration
call next fiter

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.

Also coredumping analysis of reentrant funcitons is never going to be that easy - and with instances these are reentrant.

Oh Moez, by the way, no filter module should have static variables at all.

Rob

----- 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 2:29 AM
Subject: Re: Feedback about the content processing framework

> On Wed, 31 Jan 2001, Robert Collins wrote:
>
> > At the moment, the API rule is that the first buffer will always
> > be the headers, with no body. There is a flag FILTER_EOF which
> > matches your CP_LAST_CHUNK.
> >
> > FILTER is more appropriate, because content processing is a sub
> > case of filters which are more generic.
>
> Would using different functions instead of flags be a "cleaner", less
> confusing/error-prone approach?
>
> myfilterNoteHeaders(buf, ...) // guaranteed to be called once
> myFilterNoteData(buf, ...) // called zero or more times
> myFilterNoteEnd(...) // guaranteed to be called once
>
> If nothing else, it will make coredump analysis easier. :)
>
> Just a thought.
>
> Alex.
>
>
Received on Wed Jan 31 2001 - 13:15:50 MST