Mailing-List: contact modperl-help@perl.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <42C3E9DE.6090902@modperlcookbook.org>
Date: Thu, 30 Jun 2005 08:47:26 -0400
From: Geoffrey Young <geoff@modperlcookbook.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040927
MIME-Version: 1.0
To: Torsten Foertsch <torsten.foertsch@gmx.net>
CC: modperl@perl.apache.org
Subject: Re: [PATCH]Apache::IncludeHook
References: <200506292009.42768.torsten.foertsch@gmx.net>
 <42C2E975.7080900@modperlcookbook.org>
 <200506292205.04648.torsten.foertsch@gmx.net>
In-Reply-To: <200506292205.04648.torsten.foertsch@gmx.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Torsten Foertsch wrote:
> On Wednesday 29 June 2005 20:33, Geoffrey Young wrote:
> 
>>patch applied and will be part of the next release.  since it's the only
>>change I might wait a little bit before getting it to CPAN, but probably
>>not more than a week.
> 
> 
> BTW, I have learned that the first arg to sub is not an Apache2::RequestRec 
> but an Apache::IncludeHook object that is based on Apache2::RequestRec. In 
> mp1 this arg was the request object and it was okay. Now mod_include is 
> implemented as a filter. Hence, the first arg being a Apache2::RequestRec 
> looks somewhat unnatural for me. 

well, just because a thing is implemented as a filter doesn't necessarily
mean the thing implemented is itself a filter :)

> I understand there are portability issues. 
> But maybe it would be nice to have the current filter instance accessible via 
> the Apache::IncludeHook object? 

the "should we" aside, I'm not really sure how you might use it.  the SSI
calls are being made from within the context of filtered document, so what
exactly might you be filtering?  on the surface it actually sounds like a
recipe for disaster.

> Also some kind of context would be nice since 
> $f->ctx seems to be used by mod_include. Sometimes it may be useful to have 
> an interface to the base object $r->{_r}. But when the current filter is 
> accessible it can be fetched via $r->current_filter->r.
> 
> What do you think?

again I'm not sure. $f->ctx is for sharing data between multiple calls to
the same filter as part of moving the filter data around.  that is,
ordinarily your filter is called once for each chunk of data sent to it, so
you sometimes need a context to keep track of where you are.  this behavior
is something we don't see with SSI handlers - mod_include needs a context,
but each tag is itself processed only once, so there's no need for a context
to keep track of things between multiple invocations.

hmm... so, no I don't think Apache::IncludeHook ought to provide a
filter-like interface.  thinking about it now I might describe it this way:
mod_include is the filter, dispatching off to simple mechanisms, like
including files or executing scripts.  if you want the scripts to execute
slowly use the exec tag.  if you want them to execute quickly, or you want
access to $r, use the perl tag.  if you want a filter then write your own.

but I'm open to alternative interpretations, especially if you can present a
use case :)

--Geoff