Geoffrey Young wrote:
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.:
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 ]
will that work with stacked handlers?
I hope, yes. Haven't looked yet at how to change the handlers struct to accept
an optional argument.
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);
ok, those are cool.
But they will work exactly the same as 1.
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.
ok, but I don't understand why this can't follow the same mechanics of
attributes, since they work just fine for the other stuff.
It's not the same. Currently we use attributes to learn whether the handler is
designed for Request or Connection. But we already know the name of the
handler. So we don't have to go through all $__PACKAGE__::{CODE} entries. With
filter_init, we don't know how that function was named, and looking it up,
might be slow.
besides, the first two interfaces are fine, but it's the final one that
I think is most important and will be used most often. the filter_init
mechanism is really in place for conditional GETs (though it can be used
for other things :) and in instances where you have an output filter
that requires proper conditional GET interaction, requiring a separate
handler to be configured for another phase seems really separated and
not at all what you would want as a module writer. registering the init
within the filter itself makes it non-optional for users of your
module. it also makes your module self contained and (more) easily
configured.
so, I guess what that means to me is that the interface ought to be as
"pretty" as all the rest, since it's going in your module most of the
time. given
sub FILTER_INIT {
...
}
sub handler : FilterResponseHandler {
...
}
FILTER_INIT seems almost kludgy. at it's best it's non-intuitive and
limiting (since you can have only one). can you explain why you don't
think attributes will work? after all, they're used quite a bit :)
I did above.
anyway, that's probably enough squabbling. let's try and get some
prototype working - we can always argue the interface later :)
so, I guess since filter_init only gets a filter record, we'd need
something similar to modperl_filter_new that only accepted a filter
record? do we need to populate those wbucket entries in the filter record?
Nope, but first I want to add the add/remove functionality. Meanwhile if you
come up with a better interface, please, speak up.
__________________________________________________________________
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
|
