Graham Dumpleton wrote:
On JIRA, the following issues are still marked as incomplete for mod_python
version 3.3. I have noted my own comments about where they are up to and
what I think still needs to be done.
MODPYTHON-93 Improve util.FieldStorage efficiency.
This was actually marked as resolved but reopened because it was discovered
that changes meant that Trac <=0.9.6 would no longer work. The changes were
also backed out of mod_python 3.2.X branch and not released in 3.2.10.
At this point I believe we have agreed that code in 3.3 would be left as is and
people would need to use Trac >=0.10, which has now been release, with
mod_python 3.3 or later.
I know we've hashed this over a couple of times, but creating this
dependency still makes me nervous.
There was comments as to whether util.FieldStorage needs to have more
dictionary like access, but at this point I believe we should mark this issue
as resolved and if people want dictionary like access, they can open a
separate JIRA issue for that and we deal with it in a future release.
In summary, I believe we should mark this as resolved.
MODPYTHON-104 Allow Python code callouts with mod_include (SSI).
The code for all this has been done for some time. The only reason it hasn't
been marked as resolved as no documentation has been added into core
mod_python documentation. I have separately written a article on the new
feature which is available at:
http://www.dscpl.com.au/wiki/ModPython/Articles/BasicsOfServerSideIncludes
I have no problem as this being used as basis for core documentation.
I had been holding off integrating it because of contention over whether we
could use wiki for documentation or not.
In summary, need to still keep this open until some documentation added
to core mod_python documentation.
MODPYTHON-127 Use namespace for mod_python PythonOption settings.
I have made code changes but not committed them back to repository. Jim
has committed some documentation changes related to it already though.
Some more documentation changes are probably required where options are
mentioned in relation to features they affect.
I had posed question about whether mod_python.session.database_directory
should also be added as a general fallback in cases where which type of
filesystem based session was not going to be known. Jim responded with +1,
but his explicit vs implicit comment made me unsure which proposal he
was agreeing with. Thus nothing done about that yet.
Sorry about that. :) I 100% agree with your proposal. By explicit I
meant using your proposed scheme makes it more obvious to the user what
they are configuring. So yes, we should include the additional
PythonOption settings.
In summary, bit more work to do.
MODPYTHON-143 Implement and integrate a new module importer.
Code has been done, except for extra bit more logging of exceptions for when
modules hooks are called and a problem occurs. Also need to update the
documentation.
In summary, more work to do but mainly documentation.
MODPYTHON-186 Build process not using correct values from Python
config Makefile.
This is only known to be an issue on Mac OS X when the very latest
compiler tool chain software given out at Mac developer conference
is used. It may only affect new Intel Macs. Someone did suggest they
would come back with required changes but that hasn't happened.
Personally I would say we don't attempt to address this in 3.3 and defer
it till later.
And I'm Mac-less, so I can't help there anyway.
MODPYTHON-190 Python 2.5 support.
From what I have seen, people are already using Python 2.5, thus is there
any urgency on this? All I can figure is that by not making changes you will
not be able to work with really large data, or will it all crash badly on a 64
bit platform with 64 bit support compiled in.
I don't know the answers to this and no one else (doesn't even have to be
one of the committers) has stepped up to do the work and work out what
the required changes are.
Personally I would say we don't attempt to address this in 3.3 and defer
it till later.
I've actually being going through the code in the last couple of days
and was about to ask some questions about this. So I've added comments
to code sections identified by ssizecheck.py. Should I check in the code
with these comments so we can keep track, or just attach a patch to the
JIRA issue?
Personally, I would like to see this fixed for 3.3. The biggest problem
I have is the lack of a 64-bit machine to test on. On the other hand, I
don't have a 64-bit machine, so it doesn't affect me personally if we
don't deal with it.
At the very least we should make sure we include 32-bit python 2.5 in
our testing round.
MODPYTHON-193 Add req.hlist.location to mirror req.hlist.directory.
I have done most of the code for this and now just sorting out some
problems with trailing slashes getting added when they shouldn't. Also
need to still update Session code and ensure None is returned for handler
directory when not used in a directory.
In summary, a bit more work to do.
So that is where we are at. Can I get some agreement that we will:
1. Mark MODPYTHON-93 as resolved.
-0
As I said above, I'm still nervous about this, but I wouldn't veto the
release if it is not.
2. Defer MODPYTHON-186 till later
+1
3. Defer MODPYTHON-190 till later.
-0
Again, I'd prefer to see this resolved, but I wouldn't veto the release
if it is not fixed.
Finally, is there anything else in outstanding issues (not listed here)
that people believe need to be address for mod_python 3.3?
There are a couple of things that can be cleaned up and marked as closed.
Add get_session() method to request object.
http://issues.apache.org/jira/browse/MODPYTHON-59
This idea was pretty much shot down, but there is still a bit of
residual code that should be cleaned up. I'll do that and mark it as
closed. I think the idea still has merit, but it would be better to
start from scratch at some future date.
Add a security section to the documentation.
http://issues.apache.org/jira/browse/MODPYTHON-19
Most of what I've put together is really not mod_python specific. I
think this would be better off in the wiki, so I propose that we do that
and mark this issue as closed.
Although there is no JIRA issue for it, I'd like to see us do a quick
code cleanup. I see lots of complier warnings about unused variables and
it would be nice to excise the offending bits of code. I figure we are
more likely to spot real problems if the compiler is spewing less noise.
If there are no objections I'll do this over the weekend.
Jim
