this probably belongs just on dev :) Stas Bekman wrote:
ok, I've looked at the current API docs a bit more, and I think that attributes are just fine - I hadn't realized that so much is attribute driven (I haven't looked at the docs in a while :)Geoffrey Young wrote:
But the $filter object doesn't exist till it was called by Apache, it's created dynamically when Apache calls the filter. So I'm not sure where you want to call $filter->init(). If this can be done in the first filter invocation, like I've suggested in my first reply using the ctx flag, than you have this feature already. Please try it and let us know if it does what you want.
ok, I'll try it next week, but I can tell you that by the time the filter is called it's too late - you need to run the init routine _before_ any handlers run for this to work properly. that's why it ought to be able to happen on module load, or at least outside of the handler().
I understand that, but you realize that $filter doesn't exist when the module is loaded. I don't know whether looping through all CODE entries and looking for one with the right attr is not too slow, but so far I've no other ideas for this other than having an optional argument in the conf file.
I think it could look like:
sub init : FilterInitHandler {
# we need some way to get at $r here, namely $r->update_mtime()
$r->update_mtime($mtime);
}
sub handler : FilterRequestHandler {
# normal stuff
}
since the call to ap_register_*_filter would be the place to add the filter_init routine, I think this would work.
if the register mechanism is dynamic enough to recognize closures like
my $mtime = (stat($package))[9];
sub init : FilterInitHandler {
$r->update_mtime($mtime);
}
updating $mtime ( and init() ) on Apache::Reload-type actions, then we're golden. I wouldn't worry so much about the speed implications - this functionality is going to be integral for anybody concerned with conditional GETs (which should be everybody), and in the end that will lighen the server load :)
BTW, I don't see how filters are working at all now: the prototype for ap_register_*_filter was changed with this commit:
http://marc.theaimsgroup.com/?l=apache-cvs&m=102525364520027&w=2
so, stuff like mod_cache.c is now using this in CVS:
ap_register_output_filter("CACHE_IN",
cache_in_filter,
NULL,
AP_FTYPE_CONTENT_SET-1);
but mod_perl.c uses this:
ap_register_output_filter(MP_FILTER_REQUEST_OUTPUT_NAME,
MP_FILTER_HANDLER(modperl_output_filter_handler),
AP_FTYPE_RESOURCE);
shouldn't we change the parameter list on the mod_perl side, or am I missing something?
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
