httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: Anywhere to go for a summmary of I/O filtering?
Date Mon, 24 Jul 2000 18:59:59 GMT
It is a complete red herring to focus on how async will impact the filter
design. Async will impact how modules are written, how filters are written,
and how the overall server is designed. "we can't add filters because async
will change them" is wrong-headed... using that approach, we would say
"the module/Apache API is wrong and we should not implement any new modules
because async will change them."

A possible, future async model is definitely not a reason to be concerned
about today's filtering model.


On Mon, Jul 24, 2000 at 01:16:15PM -0500, William A. Rowe, Jr. wrote:
> That's fine.  Forewarn and forearm module authors that filtering is subject
> to overhaul when async is implemented in 3.0 ...
> What 3.0 major feature did you have in mind when you suggested that async 
> is a feature for 4.0?
> I have only two concerns:
>   1) async may become a major consideration for authors/administrators when
>      it comes to choosing their web server in 2002, if it's not already.
>   2) async may blow our filters design out of the water if we don't bear it
>      some consideration (not _implementation_, only _design_) as we create
>      the filter api.  I don't want to give the authors in 2002 the choice
>      between rewriting their module for Apache and rewriting for another
>      platform.  If we bear it in mind, we can avoid big rewrites (unless
>      they want to fully exploit async, which is a different issue.)
> If we design async, and then stub it for filters, we can keep moving and 
> no code will be harmed in the production.  When we are ready to expose it,
> then we can revamp the server.  As it is, I'm reviewing mod_isapi to fully
> implement the API, but emulate async for authors so they aren't coding 
> twice, and for admins who aren't interested in arguing with the coder.
> Bill

Greg Stein,

View raw message