httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: cvs commit: apache-2.0/htdocs/manual/developer layeredio.html index.html
Date Sun, 26 Mar 2000 11:32:48 GMT
Absolutely!

As a module writer, I should not be concerned with layered I/O. Not at
all!

Modules that are interested in inserting a layer should do so during the
request processing. Content-generating modules should continue to use
ap_get_client_block() for reading, and ap_r* for writing. Layers should be
underneath those covers.

-1 on layered I/O if it is visible to a content-generating module.

Cheers,
-g

On Sun, 26 Mar 2000, Ralf S. Engelschall wrote:
>...
> Hmm... if I've perhaps still not understood the stuff correctly, please
> complain. But you assume that the decision for using layered I/O is done
> by the handlers which come first (for output handlers), i.e. they have
> to know or guess that there will be handlers which want to act on their
> stuff later. I think this logic is unreasonable and is in the wrong
> direction. Instead a handler never should have to care whether other
> handlers might exists in the data flow. And if another handler wants to
> intersect the data flow it should be always have the chance to do it
> (and not have to hope that the previous handler were friendly enough and
> allow it).
> 
> Whether another layer exists in the data flow is only the decision of
> the handler which creates the layer and should never affect any existing
> handlers. In practice your approach seems to lead to handlers which
> _always_ return RERUN_HANDLERS to make sure others get a chance (think
> perhaps about a compression or encryption layer - it would require that
> all handlers are friendly in order to work for both static pages, CGI,
> etc.).
> 
> So I think, the more reasonable approach would be that every handler
> just uses the BUFF as it would directly writing to it. And if some other
> handler wants to filter this stuff, this fact is _internally_ handled
> by the BUFF code and doesn't require any changes to the handlers. Or
> in short: a handler should not have to know whether its output is
> post-processed or pre-processed or not touched at all.
> 
>                                        Ralf S. Engelschall
>                                        rse@engelschall.com
>                                        www.engelschall.com
> 

-- 
Greg Stein, http://www.lyra.org/



Mime
View raw message