perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: a new stacked handlers paradigm
Date Tue, 03 Jun 2003 07:40:47 GMT
Geoffrey Young wrote:

>>> 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:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message