On 18/12/2005, at 3:09 AM, Jim Gallacher wrote:
We had talked about doing a 3.2 final release just after ApacheCon.
A couple of things have cropped up which we have (or should) fix, but
these will not be substantial changes from 3.2.5b. As such I think we
should do another beta followed very quickly by a final release. Any
new bugs that crop up will have to wait for a 3.2 bug fix release
sometime in January or February.
How about a beta on Dec 18 (if possible) followed by a final release
before Dec 31?
If we are going to have another 3.2 beta release, can I ask for a very
minor
change.
The reason I am after the change is that I have been working on a new
importer
for mod_python which addresses the problems I have described in:
http://www.dscpl.com.au/articles/modpython-003.html
With the way that mod_python is at the moment, in order for anyone to
be able
to trial this new importer when ready, they would need to patch the
existing
mod_python source code. I see this as a roadblock to getting anyone to
try it
out and help ensure it is compatible and performs adequately.
With just a very minor change to expose the callback object created when
mod_python is initialised, I would be able to provide the new importer
as
a package which could be optionally enabled for a specific Python
interpreter
instance using the PythonImport directive.
For example, you might specify that for just the Python interpreter
instance
called "new_importer_testing", you want it enabled. To do that you
would use
something like:
PythonImport mod_python.future.importer new_importer_testing
Note using "mod_python.future" as an example only, am not suggesting
that the
importer be a part of mod_python core as yet.
Because PythonImport is required to enable it, you could run it along
side of
existing web applications and they will not be affected. To test it
out, you
would use PythonInterpreter directive to specify your test code runs in
the
"new_importer_testing" instance. After initial testing you could try it
on
your more important web applications by specifying PythonImport for the
new
importer module in interpreter context where your other code is
running, ie.,
usually the virtual host name.
As to the change itself, in init() function of
lib/python/mod_python/apache.py
where it currently has something like:
_interpreter = None
_server = None
def register_cleanup(handler,data=None):
_apache.register_cleanup(_interpreter,_server,handler,data)
def init(name,server):
"""
This function is called by the server at startup time
"""
global _interpreter
global _server
_interpreter = name
_server = server
return CallBack()
change it to:
_interpreter = None
_server = None
_callback = None # XXX ADD THIS LINE
def register_cleanup(handler,data=None):
_apache.register_cleanup(_interpreter,_server,handler,data)
def init(name,server):
"""
This function is called by the server at startup time
"""
global _interpreter
global _server
_interpreter = name
_server = server
# return CallBack() # XXX REMOVE THIS AND ADD NEXT THREE LINES
global _callback
_callback = CallBack()
return _callback
In short, cache the instance of the CallBack object that is created
within the
mod_python.apache module so that it is accessible. That is all, really
quite]
simple.
This will allow a module imported using PythonImport to override the
various
dispatch methods of the CallBack object instance so as to allow the
experimental
importer to be installed in its place and be used thereafter just for
the
interpreter instance that PythonImport is applied to. Ie., can be done
in
isolation this way and not affect a whole site.
Having this hook and providing an easy means of people being able to
optionally
test the new code would be very important as far as ensuring it can be
well
debugged with actual use before consideration is given to including it
in
mod_python itself as a replacement.
Comments????
Graham
