Re: rfc: new filtering APIs

[Geoffrey Young]

Stas Bekman wrote:

Geoffrey Young wrote:

Finally, other than add/remove filters APIs which we have talked about, what other APIs do you want for filters?

is there an interface to filter_init?

see the discussion on

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9673

or CHANGES file for a description of why it was added.

this API may be crucial to mod_perl developers who want to handle conditional GET requests properly with their filters.

First of all you can always do:

unless ($filter->ctx) {
# filter is called for the first time
# and this code won't be run only once
$filter->ctx(1);
}

so if you want to do something once, or e.g. remove yourself you can do it in this block. So it seems to be similar to filter_init. Or am I wrong here?

no, you need the real filter_init hook.

the issue here is that default_handler has meets_condiditions() logic in it, so it makes decisions about whether or not to send content down the chain. this is generally bad for filters, since they may have their own criteria for determining what gets involved in making that decision - if default-handler doesn't have all the information, it can return NOT_MODIFIED when the filter would have chosen to re-modify the content (based on, say, the fact that the version of the code has changed so it does things differently now).

filter_init is a hook that runs code before any handlers run, I suspect for adding calls to update_mtime() and other similar things.

I agree that having a dedicated filter_init seems to be cleaner and probably more efficient.

If filter_init is wanted, how should it be set by the Perl code? Using an optional second argument to the filter configuration?

PerlOutputFilterHandler MyFilter MyFilter::init

I would want at least a real-time interface for this, something similar to

$filter->init(sub {shift->update_mtime($package_mtime)} );

sub handler {
...
}

it's important that the filter be able to insert this logic itself without relying on httpd.conf stuff. that makes the filter self-contained and a bit more DWIMmy. of course, the subroutine/coderef would have to run on each request, similar to $r->register_cleanup, just at the other end.

Also can you please give me some useful test I can play with? Probably one of the examples from your book will do ;)

I'm working on something now, but without a tie into filter_init there's not much to show :)

if you come up with the interface, I'll write the tests to make sure it does what we need.

--Geoff