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 :)
 
> 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:

        moduleEntry(bunch-of-flags) { // public
                if (bunch-of-flags & flag1)
                        processFlag1() // internal
                else
                if (bunch-of-flags & flag2)
                        processFlag2() // internal
                else
                ...
        }

Since the flags you were talking about describe non-overlapping
states, the above may be preferable (but still error prone) to [the
usual]:

        moduleEntry(bunch-of-flags) {
                if (bunch-of-flags & flag1)
                        1000 lines with a couple of returns
                
                if (bunch-of-flags & flag2 & something-else)
                        1000 lines with a couple of returns
                ...
        }

> 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". :)

Anyway, that was just a suggestion...

Alex.
Received on Wed Jan 31 2001 - 13:30:21 MST