Geoffrey Young 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 :)I gave this some more thought and I think that this approach would be too ineffective. I think if we ever need only *one* filter_init function per package (filter), we could have a special name for it, similar to INIT, BEGIN, etc. e.g.:
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.
sub FILTER_INIT {
# ....
}
This will make the lookup much faster. Though we have a problem of not being able to have more than one filter_init function per package. Which is not so good, if we have several filters implemented in the same package.
So currently I have the following spec in my head.
Three ways to add the init function:
1. httpd.conf
PerlInputFilterHandler handler [ init_handler ]
2. API:
(to be run in PreConnection or HeaderParser stages to dynamically register the filters)
add_filter(..., &handler, &init_handler);
2.1 could probably have
add_init_filter("filter_name", &init_handler);
3. special function
If none of the above has used the init_handler option, and a special function FILTER_INIT exists, use it as init_handler. If you need more than one init_handler functions per package, use 1. or 2.
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 :)
Interesting ;)
BTW, I don't see how filters are working at all now: the prototype for ap_register_*_filter was changed with this commit:MP_FILTER_HANDLER is macro, that allows to compile mod_perl with older Apache versions, which didn't have that argument in their API.
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?
It's a magic...
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
