Hi Graham, It looks like this can't break anything since the init() function is called once per interpreter (no multithreading problem). So +1 for me.
Regards, Nicolas 2005/12/18, Graham Dumpleton <[EMAIL PROTECTED]>: > > 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 > > >
