Re: modifying $subr->run

[Perrin Harkins]

Todd Finney wrote:
> 
> This another follow-up to a previous thread, "maximum
> (practical) size of $r->notes", from last week.   We're
> trying to redirect the output of $subr->run(), and return
> it as a variable instead of sending it to the browser.

Usually people consider this, realize that it's hard, and find a way to
do what they need in perl without going back to Apache.  If all of your
subrequests are things like static files, CGI, and SSI, you may find it
easier to generate the same results from perl code than to try and
modify core Apache architecture.  Libraries for doing most common tasks
exist (Apache::SSI, Apache::PerlRun, Apache::File).

- Perrin

Re: modifying $subr->run

[Todd Finney]

At 02:14 AM 11/6/00, Perrin Harkins wrote:
>Todd Finney wrote:
> >
> > This another follow-up to a previous thread, "maximum
> > (practical) size of $r->notes", from last week.   We're
> > trying to redirect the output of $subr->run(), and 
> return
> > it as a variable instead of sending it to the browser.
>
>Usually people consider this, realize that it's hard, and 
>find a way to
>do what they need in perl without going back to 
>Apache.  If all of your
>subrequests are things like static files, CGI, and SSI, 
>you may find it
>easier to generate the same results from perl code than to 
>try and
>modify core Apache architecture.  Libraries for doing most 
>common tasks
>exist (Apache::SSI, Apache::PerlRun, Apache::File).

Thanks, Perrin.  The handler uses Apache::File to serve 
static files.  I've just read the Apache::SSI 
documentation, and it looks like we can use that to cover 
most of the components.  Many of them have yet to be 
written, so it's no problem adapting to the differences in 
argument handling between CGI and .

The only difficulty then remaining is the existing CGI 
scripts that this system wraps.  There are several dozen of 
these in place already, and changing the argument handling 
would be rather tedious.  Do you know of an easy method for 
handling that translation, 'easy' meaning 'anything easier 
than changing all the scripts or Apache itself'. :)

Thanks again, and thanks to those that have been offering 
advice off-list.

cheers,
Todd

Re: modifying $subr->run

[Ken Williams]

[EMAIL PROTECTED] (Todd Finney) wrote:
>>Todd Finney wrote:
>> >
>> > This another follow-up to a previous thread, "maximum (practical)
>> > size of $r->notes", from last week.   We're trying to redirect the
>> > output of $subr->run(), and return it as a variable instead of
>> > sending it to the browser.

[...]

>The only difficulty then remaining is the existing CGI 
>scripts that this system wraps.  There are several dozen of 
>these in place already, and changing the argument handling 
>would be rather tedious.  Do you know of an easy method for 
>handling that translation, 'easy' meaning 'anything easier 
>than changing all the scripts or Apache itself'. :)

Yeah, check out Apache::Filter, which has an Apache::RegistryFilter
module bundled with it.  That should let you filter the output of your
scripts, if that's what you're after.


  ------
  Ken Williams Last Bastion of Euclidity
  [EMAIL PROTECTED]The Math Forum

Re: modifying $subr->run

[Perrin Harkins]

On Mon, 6 Nov 2000, Todd Finney wrote:
> The only difficulty then remaining is the existing CGI 
> scripts that this system wraps.  There are several dozen of 
> these in place already, and changing the argument handling 
> would be rather tedious.  Do you know of an easy method for 
> handling that translation, 'easy' meaning 'anything easier 
> than changing all the scripts or Apache itself'. :)

You can get nearly any CGI script to run under Apache::PerlRun or
Apache::Registry.  And, as Ken pointed out, you can use Apache::Filter or
various other methods for collecting the output without sending it
straight to the browser.
- Perrin