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 "Damjan Georgievski (JIRA)" <ji...@apache.org> on 2006/06/12 07:30:31 UTC

[jira] Commented: (MODPYTHON-74) Add a WSGI handler to support WSGI-based frameworks

    [ http://issues.apache.org/jira/browse/MODPYTHON-74?page=comments#action_12415819 ] 

Damjan Georgievski commented on MODPYTHON-74:
---------------------------------------------

I vote for this feature to be added in mod_python.
I know some of the mod_python developers don't quite like WSGI but consider that today there are not much exlusively mod_python applications (and some people need/want to use web servers other than Apache). 
This means that, current applications can't depend on mod_python features, but most often they don't even need the special mod_python features.

Current applications also implement special glue code to use the app with mod_python, scgi, cgi etc.. In the future, applications developers would want to avoid that, and you can see that almost all of the new web-app development is based on WSGI. You can even run Zope in a WSGI server (I wonder if anyone tried to do it in mod_python/WSGI).

Including modpython_gateway (possibly as mod_python.wsgi) in the mod_python distribution will make mod_python an easy choice for serving WSGI applications without the need to hunt down mod_python WSGI implementations.

Also I'd suggest that some features are implemented in modpython_gateway:
- sendfile support (http://www.python.org/dev/peps/pep-0333/#optional-platform-specific-file-handling)
- more robust PATH_INFO and SCRIPT_NAME detection, possibly without the "PythonOption SCRIPT_NAME" hack.... well, I think this might not be possible but it would be great if is.

> Add a WSGI handler to support WSGI-based frameworks
> ---------------------------------------------------
>
>          Key: MODPYTHON-74
>          URL: http://issues.apache.org/jira/browse/MODPYTHON-74
>      Project: mod_python
>         Type: New Feature

>   Components: core
>     Reporter: Nicolas Lehuen
>     Priority: Minor
>      Fix For: 3.3

>
> There is a complete implementation here :
> http://www.amorhq.net/blogs/index.php/fumanchu/2005/08/11/wsgi_wrapper_for_mod_python

-- 
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: [jira] Commented: (MODPYTHON-74) Add a WSGI handler to support WSGI-based frameworks

Posted by Graham Dumpleton <gr...@dscpl.com.au>.
On 12/06/2006, at 3:30 PM, Damjan Georgievski (JIRA) wrote:

>     [ http://issues.apache.org/jira/browse/MODPYTHON-74? 
> page=comments#action_12415819 ]
>
> Damjan Georgievski commented on MODPYTHON-74:
> ---------------------------------------------
> Also I'd suggest that some features are implemented in  
> modpython_gateway:
> - sendfile support (http://www.python.org/dev/peps/pep-0333/ 
> #optional-platform-specific-file-handling)
> - more robust PATH_INFO and SCRIPT_NAME detection, possibly without  
> the "PythonOption SCRIPT_NAME" hack.... well, I think this might  
> not be possible but it would be great if is.

And there be the lid on the can of worms. What you want is more than  
just a minimal
basic WSGI gateway, you want other stuff as well. Other people will  
probably want
other stuff down the track as new WSGI components are dreamed up  
which can only
be implemented by hooking off low level features of the actual web  
server. Thus the
burden of developing and supporting it grows and grows with an  
expectation that it
be the existing mod_python developers that do the work even though  
our hands are
already full just fixing the existing problems in mod_python.

The far preferable approach would be for others to step up and dedicate
themselves to developing and supporting a mod_python/WSGI gateway as a
distinct package hosted on its own site. If someone else is prepared  
to do this, I
don't think you'll will have problems with the existing mod_python  
developers and
other users giving feedback on issues and changes. I wouldn't even  
see any problems
with the discussion being on the mod_python developers list, but  
please keep the
project and ownership of it separate.

One benefit of the package being separate would be that it could be  
made to work
with any of the major versions of mod_python (2.7, 3.1, 3.2,  
3.3 ...). If part of mod_python
itself it would only be available with the latest version of  
mod_python which defeats the
idea that which version of mod_python wouldn't matter, something  
which would
be important for what WSGI promotes. Being separate also means you  
aren't constrained
to the mod_python release dates.

Thus, there is nothing stopping someone creating a SourceForge (or  
whatever is the
flavour of the month) project now and you could have it very quickly  
for any version
of mod_python. Otherwise, wait perhaps until nearer the end of the  
year when the next
major version of mod_python is ready. Which would you prefer?

Sorry to be so negative, maybe I'm just grumpy because after a 8 hour  
plane flight,
home, the first time for business class for me, I get stuck in the  
plane at the airport gate
for an hour because the air bridge broke down. In the end was one of  
the last to get
off the plane along with first class and the pilot. Stupid airport.  :-(

BTW, this means I am back home now, so you should see me starting to  
ramp up on
changes to mod_python again. ;-)

Graham