(going in circles)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.
yes, you could. however, that should not be required. for a filter to be self contained (read: taking care of everything with a single PerlOutputFilterHandler directive) it needs access to this. we could work around some trickery for module load to add config directives or something, but there really should be no need for that kind of thing - Apache has the filter_init hook for precisely this reason, so we should get access to it.
/me points to design.pod - Provide complete access to the Apache C API via the Perl programming language.
:)
well, that's kinda true, but not really. if you want a filter that accurately handles conditional GET requests, then you need _something_ to circumvent the meets_conditions() calls in default_handler (and others). this is the way the Apache API chose to handle it, so we ought to follow suit (whether it makes sense from mod_perl's standpoint or not I guess).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.
that you might be able to use filter_init without a filter could be interesting, but the more I think about it, the fixup stage essentially does the same thing for handlers unrelated to filters, so that should be sufficient.
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.
hmm...
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.
yes, we'll need that one in any case :) --Geoff --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
