Re: cvs commit: apache-2.0/htdocs/manual/developer layeredio.html index.html

[Ben Laurie <be...@algroup.co.uk>]

"Ralf S. Engelschall" wrote:
> 
> In article <20...@locus.apache.org> you wrote:
> > rbb         00/03/25 07:45:01
> 
> > [...]
> >   <H2>Taking advantage of layered I/O</H2>
> >
> >   <P>In order to make a module use layered I/O, there are some modifications
> >   needed.  A new return value has been added for modules, RERUN_HANDLERS.
> >   When a handler returns this value, the core searches through the list of
> >   handlers looking for another module that wants to try the request.
> >
> >   <P>When a module returns RERUN_HANDLERS, it must modify teo fields of the
> >   request_rec, the handler and content_type fields.  Most modules will
> >   set the handler field to NULL, and allow the core to choose the which
> >   module gets run next.  If these two fields are not modified, then the server
> >   will loop forever calling the same module's handler.
> >
> >   <P>Most module's should not write out to the network if they want to take
> >   advantage of layered I/O.  Two BUFF structures have been added to the
> >   request_rec, one of input, and one for output.  The module should read and
> >   write to these BUFF's.  The module will also have to setup the input field for
> >   the next module in the list.  A new function has been added, ap_setup_input,
> >   which all modules should call before they do any reading to get data to modify.
> >   This function checks to determine if the previous module set the input field,
> >   if so, that input is used, if not the file is opend and that data source
> >   is used.  The output field is used basically the same way.  The module must
> >   set this field before they call ap_r* in order to take advantage of
> >   layered I/O.  If this field is not set, ap_r* will write directly to the
> >   client.  Usually at the end of a handler, the input (for the next module)
> >   will be the read side of a pipe, and the output will be the write side of
> >   the same pipe.
> 
> 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.

+1.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html