You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mod_python-dev@quetz.apache.org by Jim Gallacher <jp...@jgassociates.ca> on 2005/12/17 17:09:19 UTC
3.2.6b?
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?
Jim
Re: 3.2.6b?
Posted by Nicolas Lehuen <ni...@gmail.com>.
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 <gr...@dscpl.com.au>:
>
> 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
>
>
>
Re: 3.2.6b?
Posted by Graham Dumpleton <gr...@dscpl.com.au>.
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