Re: rfc: new filtering APIs

Geoffrey Young wrote:
> > > yeah, that was my thought.  I started working on that but couldn't 
> > > quite see all the pieces.  here's what I have so far - it should 
> > > compile cleanly and be good for a start, but it doesn't do anything 
> > > (yet) due to the missing hooks.
> >
> >
> >
> > But then you create a whole new filter, so whatever work is done in 
> > filter_init is lost. I guess you could still pass notes via the 
> > connection record. I thought that you want to create a filter early, 
> > run init on it and then use the same filter to do the real filtering.
>
> well, I'm thinking about two scenarios here.
>
> the first is that a filter only needs filter_init to do some scut work - 
> like update_mtime(), which is a required activity but does not need to 
> be communicated _back_ to the filter that called the init.  this is the 
> type of thing that mod_include does (sets f->r->no_local_copy = 1) and 
> that I was first interested in.

Can't you just use an early request phase for that? For protocols you can use 
PreConnection phase.

> the other is when info _does_ need to come back to the calling filter, 
> say via $filter->ctx or something.
>
> the first could be handled with just a hook into filter_init - maybe by 
> adding a whole new NULL filter with just the init (which probably won't 
> work, but is worth a try), or adding a no-op filter.  this would 
> basically allow for anybody to add arbitrary code before request 
> handlers run, which could be cool even outside of filters.

Indeed, from your requirements it looks like this filter_init has little to do 
with the real filter and you may want to have just filter_init without having 
any real filters. The problem I think (need to look deeper in the code) is 
that the request filter chain won't be called at all unless the body is 
requested by the request handlers. So your init will be missed out. But I need 
to do more checking, since the logic is not trivial.

> the second gets more complex - you need a way to associate the handler() 
> routine with the init() routine in the handler so you can register the 
> filter all at once.  or maybe you don't if $filter->ctx is somehow 
> magical, I dunno.  all of this is requiring a pretty steep internals 
> learning curve on my part :)

I was planning to workout the second one if possible.

> at any rate, my thought was to prototype the first part and save the 
> second for later, after we get filter_init working in at least some 
> fashion.

See above.



__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@xxxxxxxxxx http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com