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.
Agreed. You can still do stacked handlers for RUN_FIRST handler ala mp1, by returning the less intuitive Apache::DECLINED
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.
Sure, we can always write a sub-class of registry that returns Apache::DECLINED. e.g. Apache::RegistrySH (stacked handlers). It can simply call SUPER->handler and then replace Apache::OK with Apache::DECLINED and return it.
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.
Sure, I'm just bouncing other ideas off you ;) Some APIs have too many arguments to my liking.
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.
sure. I'm just worried that when we do drastic test changing we may lose certain cases that get tested. So it's always better to write more new tests and not touch existing ones other than fix them.
__________________________________________________________________ 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]
