at any rate, I think that blindly running all stacked Perl handlers for each phase is wrong. it does not keep with the nature of what Perl handler writers want to do, namely interact transparently with Apache as though they were writing C handlers. having stacked handlers behave differently in C and Perl is confusing and, as it turns out, unnecessary - while for the first four stages it will probably impact people very little (and only in a good way), the only real value in mp1 in having handlers return OK _and_ running the next handler was with content handlers, but in 2.0 this is what output filters are for :)
+1, good stuff, but see more discussion below
:)
so, what I'm suggesting is that we make the stacked handler mechanism more intelligent and Apache-like, and let the phases behave the same way for Perl handlers as they do for Apache. that is, let handlers returning OK end the phase for translation, authen, authz, type-checking, and content.
Check:
http://perl.apache.org/docs/2.0/user/handlers/intro.html#Single_Phase_s_Multiple_Handlers_Behavior
there is at least process handler that is of the same kind.
ok, thanks. I guess we'll have to cover that one as well.
What about http://perl.apache.org/docs/2.0/user/handlers/intro.html#item_VOID
Now we say:
"Handlers of the type VOID will be all executed in the order they have been registered disregarding their return values. Though in mod_perl they are expected to return Apache::OK."
Should we simply call them RUN_ALL?
yeah. my thought was that this only affected the RUN_FIRST handlers. all others should iterate through the stack until finished or error.
keep in mind that in doing this we're not really taking away any functionality - handlers (in the 5 phases in question) can still return DECLINED if they want other handlers within the phase to run. all that we would be changing is the behavior of OK in phases that Apache already treats differently.
So what happens to response handlers? Do we just break the mp1 compatibility here, with an excuse that it was broken anyways? I suggest that if we change other phases we change response handlers as well.
well, I wouldn't say it was broken before. in mp1 stacked response handlers let us do content filtering, which was very, very cool. we just don't need stacked content handlers in mp2 anymore because of output filters. so, yes, we're breaking back compat, but we're replacing what used to be a hack with the official Apache way.
I guess that in mp2 the only thing that will be affected are people that want to stack Registry scripts - that feature will just plain go away I suppose. I'm unsure about whether this is a good or bad thing - Registry is bound to be popular, so we're essentially telling people that if they want to use stacking features, they need to dump Registry and move to handlers. but the streaming API is pretty easy, so I guess it's ok. or maybe we can write a special Registry cooker that returns DECLINED instead of OK to support it.
regarding the patch:
what about PerlProcessConnectionHandler? See:
http://perl.apache.org/docs/2.0/user/handlers/intro.html#Single_Phase_s_Multiple_Handlers_Behavior
yes, we'll have to add them. thanks.
I suggest to use enum instead of int for the new argument: run_all like the modperl_handler_action_e type. (enum values being RUN_FIRST/RUN_ALL/VOID to match Apache, we can probably even re-use httpd enum for this purpose if we can).
ok, I'll look into that.
Even better don't pass it as an argument, but pick it up via
modperl_handler_lookup_handlers, so not to clutter the API with too many arguments. The benefit is that you can encode the RUN_FIRST/RUN_ALL/VOID per handler and not passing them around.
that was my first thought, but I can't remember why I didn't do it that way. I'll try that approach and see how it goes.
-PerlResponseHandler TestHooks::init -PerlResponseHandler TestHooks::init::response +PerlResponseHandler TestHooks::init TestHooks::init::response SetHandler modperl
why changing the config? It was written to test the insertion of two handlers with two directives. Or did you have something special in mind?
there was a reason, but that reason doesn't make too much sense (so I won't explain it :). however...
Ahm, perhaps add a new test if you want to put so many new functionality tests inside of it? e.g. you have killed the test for Apache::DONE on the way. I'd rather leave this test alone (with only adjustements fro the new "paradigm") and add a new one to test other things.
once we settle on the treatment of stacked response handlers we can tweak the test suite to match.
thanks for your feedback.
--Geoff
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
