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?
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.
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.
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.
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 :)
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?
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
