httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: cvs commit: apache-2.0/src/modules/standard mod_cgi.c mod_include.c
Date Sun, 26 Mar 2000 16:28:26 GMT

> -1
> Per my previous mail, this design imposes too much knowledge on the module
> writer. Also, the handler changing thing before returning RERUN_HANDLERS
> seems a bit hacky.

I don't understand why this design imposes too much knowledge on module
writers, as per my response to your last mail.  There are 2 changes that
must be made, (well three if you include returning RERUN_HANDLERS).

> Sorry, but if this design was discussed at some point, then I missed it. I
> would have like to comment before you did all this work :-(

This design was discussed off-line.  Like most commits here, code means
more than talk, so I implemented it, assuming people would comment and
change it as they saw fit.  I didn't doo all that much work, most of the
work was debugging, not coding.  :-)

> It would seem that mod_include should hook the output chain in one of the
> request processing hooks (which? dunno... post-translation so that it can
> determine whether include processing is enabled, surely). The hook occurs
> underneath ap_rput*(). No module would need to change to get the benefits
> of mod_include.

But any module that wants to do what mod_include is doing would need to be
seriously hacked instead.  That's a trade off.  I would MUCH rather see
modules that are adding/modifying content not have to change too much,
because these are much more common than modules that are generating

> Your sub-thread design for mod_include seems fine, but note that all
> processors would need something similar. That general logic probably
> belongs in src/main, with a registered callback to process blocks of data:

No, the sub-thread design is a hack just to get it to work.  The real way
this should be done, is to re-write mod_include to deal well with
streaming data coming from the BUFF structure.

> Well... back to the -1. Should this change be backed out? Some portions of
> it?

Please don't back any of it out until you have read my response to your
criticisms, and some more people have looked over the code.  I would also
like the opportunity to finish the work, so people could look it over in
it's entirety.

One of the reasons this change was committed, was to get people working on
this problem.  Please, if you are going to back out this change, post a
complete design for something else that works.


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message