Re: rfc: new filtering APIs

[Stas Bekman]

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:[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]