Re: Refactoring of the test suite
Mike Looijmans wrote: Oh and if we are refactoring the tests, I want a make tests rule. I'm tired of doing: ./configure; make; sudo make install; make tests; DOH! cd test; python test.py. :) Make that make check (like autotools), to not confuse old-skool autoconfers like myself. That works for me. Jim
Re: Getting Started on mod_python 3.3.
Graham Dumpleton wrote: As Jim pointed out a while back, we need to get going on mod_python 3.3 before I fill up JIRA with another page of bug reports or suggestions. I think you already *have* filled another page since I made that comment. ;) That said, how do we want to proceed on this? Do we want to draw up an initial list of things to do with priorities, discuss them to make sure all are okay with the fix or what is proposed, possibly assign them to individuals, and then get started? Or even before that, do we want to state general aims about what we want to address in mod_python 3.3? Do we want to focus only on addressing bugs again, or look at some new features as well? This is how I would set priorities: Mark resolved bugs in JIRA as closed, just to clean things up. Try and assign most of the issues to someone. This is a bit of PR spin, but I think it looks bad when there are a large number of open issues with no assignee. To the public it may look like the project is not being actively maintained. Fix the easy bugs first so we can backport to 3.2, and be ready for a bugfix release. This does not include the various importer issues. I'd say that there are not many things in this category, but we should review JIRA to be sure. Refactor the unit tests. If we are going to do this, we should do it early in the development cycle so we have lots of time to test the test suite. Review JIRA and collect related issues. Improve documentation. New features. Grand Unified Import Theory. The order does not necessarily suggest the importance of the various issues, and of course we can work in parallel on the last 3 items. By then I might have got my SVN access sorted out. Have account, but haven't as yet tried a check out using it. BTW, I still don't have priviledges in JIRA to administer entries, ie., assign etc. Do I need/want that? How do I get that set up? It's handy to be able to assign, close and resolve issues, so I would say yes. I bevlieve Grisha can change your priviledges. Jim
ANNOUNCE: Mod_python 3.2.7
The Apache Software Foundation and The Apache HTTP Server Project are pleased to announce the 3.2.7 release of mod_python. Mod_python 3.2.7 is considered a stable release, suitable for production use. Mod_python is an Apache HTTP Server module that embeds the Python language interpreter within the server. With mod_python you can write web-based applications in Python that will run many times faster than traditional CGI and will have access to advanced features such as ability to maintain objects between requests, access to httpd internals, content filters and connection handlers. The 3.2.7 release has many new features, feature enhancements, fixed bugs and other improvements over the previous version. See Appendix A of mod_python documentation for more details. Mod_python 3.2.7 is released under Apache License version 2.0. Mod_python 3.2.7 is available for download from: http://httpd.apache.org/modules/python-download.cgi More information about mod_python is available at: http://httpd.apache.org/modules/ Many thanks to Jim Gallacher, Graham Dumpleton, Nicolas Lehuen and everyone else who contributed to and helped test this release, without your help it would not be possible! Regards, Grisha Trubetskoy
Cool feature from mod_perl : Configure Apache with Perl
Hi, I'm currently reading the feature section from mod_perl. Initially, I was trying to find information about how they cope with multithreading, multiple interpreter instantiation and code reloading, but I stumbled upon this : http://perl.apache.org/start/tips/config.html Now, I can't stand Perl, but this feature is quite cool, isn't it ? Would it be difficult to implement, say, in mod_python 4.0 ? Regards, Nicolas
For the curious : how mod_perl handles threading
http://perl.apache.org/docs/2.0/user/intro/overview.html#Threads_Support Regards, Nicolas
[jira] Commented: (MODPYTHON-29) mod_python.publisher and inbound content_type
[ http://issues.apache.org/jira/browse/MODPYTHON-29?page=comments#action_12366267 ] Graham Dumpleton commented on MODPYTHON-29: --- Whether one allows this means making some sort of policy decision about what the purpose of mod_python.publisher is. If it is mean't as a more generalised dispatcher for URLs to published functions, then it should probably allow inbound content types for POST other than those appropriate to forms. If one allows that though, then you open up a whole can of worms as to whether it should therefore restrict the method type to HEAD, GET and POST as it does now. Ie., should it start with: def handler(req): req.allow_methods([GET, POST, HEAD]) if req.method not in [GET, POST, HEAD]: raise apache.SERVER_RETURN, apache.HTTP_METHOD_NOT_ALLOWED To make it more generalised may be more trouble that its worth, so tt may well thus be best to constrain the purpose of mod_python.publisher and say that if you want to do anything else such as handle other inbound content types and other method types that you do it using some other mechanism. mod_python.publisher and inbound content_type - Key: MODPYTHON-29 URL: http://issues.apache.org/jira/browse/MODPYTHON-29 Project: mod_python Type: Improvement Components: publisher Versions: 3.1.4 Reporter: Graham Dumpleton Assignee: Nicolas Lehuen The mod_python.publisher implementation always decodes form parameters regardless of whether the method being called can accept any and also ignores whether the content type is even of a type where form parameters can be decoded in the first place. This means that it is not possible using the mod_python.publisher module to implement a method which accepts POST requests with a inbound content type such as text/xml. Attempting to do so yields an error such as: !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN htmlhead title501 Method Not Implemented/title /headbody h1Method Not Implemented/h1 pPOST to /xmlrpc/service not supported.br / /p hr / addressApache/2.0.51 (Unix) mod_python/3.1.4 Python/2.3 Server at localhost Port 8080/address /body/html The Method Not Implemented error in this case is due to FieldStorage rejecting the content type of text/xml. A check could be added to ensure that FieldStorage is only used to decode form parameters if the content type is appropriate. Ie., if not req.headers_in.has_key(content-type): content_type = application/x-www-form-urlencoded else: content_type = req.headers_in[content-type] if content_type == application/x-www-form-urlencoded or \ content_type[:10] == multipart/: req.form = util.FieldStorage(req,keep_blank_values=1) Because req.form is passed to util.apply_fs_data(), code where it is called would need to be changed to pass None instead and util.apply_fs_data() would need to be modified to see that the argument is None and not do the field conversion process of stuff in the form etc etc. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Getting Started on mod_python 3.3.
Jim Gallacher wrote .. Jorey Bump wrote: Jim Gallacher wrote: This is how I would set priorities: Try and assign most of the issues to someone. This is a bit of PR spin, but I think it looks bad when there are a large number of open issues with no assignee. To the public it may look like the project is not being actively maintained. I think the same can be said for the lack of Apache 2.2 support. Personally, I would put this (as well as backporting 2.2 support to mod_python 3.2) as the number one priority, for both PR and pragmatic reasons. The need for compatibility with Apache 2.0 2.2 is going to be an issue for quite a while, and should be addressed before mod_python undergoes some of the significant changes that have been discussed. Apache 2.2 support has already been checked into svn trunk. It's just a question of doing the backport to the 3.2.x branch once we've seen some testing. I think we should plan on doing regular 3.2.x bugfix releases so that the 3.3 dev branch can mature without the pressure making a release just to fix bugs. If we want to go down the path of having interim 3.2 bug rollup releases while 3.3 is being developed, might I suggest that we target the following for such a release in the near future. MODPYTHON-77 The Simplified GIL Aquisition patches. MODPYTHON-78 Apache 2.2 patches. MODPYTHON-94 Support for optional mod_ssl functions on request object. MODPYTHON-113 Make PythonImport use apache.import_module() via CallBack method. MODPYTHON-119 DBM Session test patches. MODPYTHON-122 Bash 3.1.X configure patches. I know that MODPYTHON-94 isn't a bug fix, but a few people have been after this one. Also MODPYTHON-113 may not seem important, but will mean that any test package I make available for new importer will work properly in all cases where module imports occur. Anyway, after trolling through JIRA, these seemed to be the important ones to me, but other might have other suggestions. Now, the question is how we manage this. Do we concentrate on these only in the trunk and get them out of the way first as a 3.2.X release, holding back any changes to test framework? Or do we merge such changes from trunk on a case by case basis in 3.2.X branch? Graham
Re: For the curious : how mod_perl handles threading
It seems that bu dfdefault Perl is not thread safe, and that they have to jump through all those hoops to ensure thread safety. There is no real lesson for mod_python, I just wanted to know how they solved this rather difficult problem. Not instantiating one interpreter per name per thread and using an interpreter pool may be an interesting optimisation, though. But I guess it's a rather complicated one. Regards, Nicolas 2006/2/13, Gregory (Grisha) Trubetskoy [EMAIL PROTECTED]: On Mon, 13 Feb 2006, Nicolas Lehuen wrote: http://perl.apache.org/docs/2.0/user/intro/overview.html#Threads_Support Which part of it - the pool of interpreters? Are they doing it out of necessity, i.e. there is no way to run multiple threads in Perl like we do in Python because of Python's GIL? Grisha
