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 <[EMAIL PROTECTED]> wrote:
When you get a chance, can you read through the JIRA issue:
http://issues.apache.org/jira/browse/MODPYTHON-129
and provide some feedback on whether you think my analysis is correct
and thus whether mod_python really needs to be changed.
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
