| Jim Gallacher 2006-02-19, 8:21 am |
| I agree with Deron's summary of your summary. 
If we make this change (and that is a +1 from me) I suggest the
following path, assuming that it is possible to control this behaviour
with a PythonOption flag:
1. mp 3.3 - New behaviour is off by default, but can be turned on using
a PythonOption. The old behaviour is deprecated and our user education
phase begins. Perhaps we can log a message at Apache startup that the
PythonOption whatever_we_call_it was not found?
2. mp 3.4 - New behaviour is *on* by default, but can still be turned
off with the PythonOption. A deprecation warning goes into the Apache
log if the new behaviour is turned off.
3. mp 3.5 - New behaviour only. The old way is deprecated and cannot be
enabled.
This means maintaining some cruft in the code during the transition, but
I think this is a big enough change that we need to either jump the
version to 4.0 or offer an easy transition path.
Jim
Deron Meranda wrote:
> On 2/17/06, Graham Dumpleton <grahamd@dscpl.com.au> wrote:
>
>
>
> Yes, I think your summary is pretty accurate. I never did
> really understand why mod_python works the way it does
> in this area (I'm sure there was a reason but I wasn't around
> then).. I always thought the Apache logic was a lot more
> useful.
>
> I am one of those who do make somewhat-significant use of
> the other apache phases. Actually what I've been doing is to
> essentially write my own "looper" wrapper, which looks like
> just one handler to mod_python, but which then implements
> more of an Apache-style loop/dispatch itself in sub-handlers.
> So at least in my case, I've been working around mod_python
> rather than letting it work for me.
>
> I guess the positive thing is that because of this I don't have
> any existing code which actually uses multiple mod_python
> handlers in the same phase; so this change in behavior is
> only positive for me. So for me it's +1 on Graham's suggested
> change in logic (but any incompatible change in behavior is
> something to think hard about).
>
> As for an example where this could even be benificial to the
> content phase, consider having different content handlers, one
> which outputs application/xhtml+xml+SVG+MathML and one
> for text/html+GIF. Then the first handler would look at the
> Accept header, etc, and if the user-agent can't support it,
> it returns a defer and then the text/html handler gets a chance.
>
> However, I still think even this new proposal is somewhat restrictive.
> For example there's no way to interleave C and Python handlers
> in the list-to-try (this is because to apache all the mod_python
> handlers look just like one handler). Of course a necessary thing
> to go along with this, would be a way to specify the hook order (one
> of APR_HOOK_REALLY_FIRST, _FIRST, _MIDDLE,
> _LAST, or _REALLY_LAST).
>
> Perhaps mod_python can actually add multiple hooks to itself
> in for each phase (at each order position), and then have a way
> for the python-handlers to optionally specify a position. If
> mod_python had no handlers for a particilar hook position it
> would just by default return a decline.
> --
> Deron Meranda
>
|