> Sounds fine to me. k
> > What happens if another module has also used REALLY_FIRST? You still > can't ensure 100% that mp's handler will run first. well, I'm going to play around with some constants and see how it all falls out. REALLY_FIRST is just -10, so maybe MOD_PERL_REALLY_FIRST could be -20 (or -50 or -36765 :) > >> that's what I propose to do immediately. as a second step, I'm going to >> look into making it either compile-time or runtime configurable. >> while I'm >> sure I can do the former, I'm convinced the latter is possible but >> probably >> not practical. > > > Don't we have a todo item suggesting to provide an API hooks ordering? > > todo/features_missing:* hooks ordering is not implemented yet > Owner: geoff yes. at the very least I think I want compile-time ordering on a per-hook level, which will get us a little beyond the options in mp1. I don't see the need for dynamic hook ordering, but if it's possible to do without a serious performance hit I guess we could do it. > > An idea to explore is to introduce pre and post hooks (for each request > phase), which will correspond to really first and really last hooks, > keeping the normal handler as it is now. i.e. register 3 hooks (or even > 5) for each phase. perhaps. it sure seems like a lot of overhead, though, where traditionally there hasn't been much of a need to run handlers both before and after a given C handler. > This of course could be a compile time thing. yeah. > > If you move all mp hooks to be really first, I think you need at least a > post hook, so if you are inside that really first hook and you realize > that you aren't ready to run, you could call ->push_handlers to reinsert > yourself into the post hook (really last) of the same phase. maybe, but I'm not convinced. doing really first will pretty much just emulate what it was like in mp1. maybe there is _some_ benefit to being able to run perl handler -> C handler -> perl handler for a given phase, but in general mod_perl either wants first dibs on RUN_FIRST handlers (where what comes next is irrelevant), or doesn't care on RUN_ALL handlers. at least, I haven't ever seen a request for "hey, I'd like to run this fixup before mod_env and this other fixup after." authentication is one place where it may make sense, but a solution is available in 2.1 already, so I'm not convinced we need the additional overhead. but if we build it, they might come :) anyway, I'll give it some thought and experiment a little and see what I can come up with in the dynamic arena. --Geoff --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
