httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Life is hard, and then you die" <ron...@innovation.ch>
Subject Re: filtered I/O ordering
Date Sat, 03 Jun 2000 11:20:22 GMT

On Wed, May 31, 2000 at 05:40:11PM -0700, Greg Stein wrote:
> On Wed, 31 May 2000 rbb@covalent.net wrote:
> > It is my opinion that it is relatively easy to order the filters using
> > either the link or hook based design.  The link is obviously a linked-list
> > and all programmers will know what to do.  The hook based design is using
> > a concept that all Apache module writers will need to be familiar with the
> > acheive the same result.  I do not see this as a stumbling block.  Other
> > thoughts?
> 
> I agree that we can get these ordered for either scheme.
> 
> However, I have two thoughts:
> 
> 1) the hook scheme tries very hard to *avoid* ordering. much of the
>    documentation, the _FIRST and _LAST type stuff, etc is all written with
>    the point of view that ordering is Badness.
> 
> 2) I believe that ordering is the typical case and would like to see a
>    model based around that. The hook model is "broadcast" with some extra
>    features to introduce order.

First, yes, ordering is quite important in almost all cases. Second, I
don't quite agree with the "with some extra features to introduce order"
part. The hook functions take as second and third parameters lists of
filters that need to precede and follow the current one, respectively,
which is really exactly the info you want to specify (e.g. "I need to
process before any transport-encodings, but after any
content-encodings", or "I need to precede any SSI processor"). In fact
I might argue that the "broadcast" part of the hook (the fourth
argument) is an extra feature ;-).

However, having said that, I find both schemes equally usable, unless
we can get into having filters tag themselves as to the type of filter
they are (transport-encoding-filter and content-encoding-filter are
two examples of what I'm thinking of, because mod_auth_digest needs
to hook itself precisely between them). If there were such tagging,
then the hooks stuff would allow folks to just specify, say, which
content-encoding and which transport-encoding to use, and they would
never have to worry about (and possibly get it wrong) where and if
mod_auth_digest would need to hook itself in. Similarly,
content-encoding filters could just specify that they must come after
any content-munging filters and content-generators, and the hook
ordering could take it from there.

Am I making any sense?


  Cheers,

  Ronald


Mime
View raw message