Making WSGIHandler the only handler / mod_python support
Gustavo Narea
I'm going to work on some patches to improve WSGI support, and I found
something that, if changed, could make my patches and django.core.handlers
simpler... As well as make it possible to use WSGI middleware with Django
under mod_python.
At the moment, Django has two so-called handlers: One for any WSGI gateway
like mod_wsgi, and another just for mod_python. Each handler has its own
request class. And the handlers and the request classes have their respective
base classes:
+ BaseHandler
- WSGIHandler
- ModPythonHandler
+ HttpRequest
- WSGIRequest
- ModPythonRequest
Instead of having these 6 classes, we could get rid of the mod_python handler,
and then merge the base and WSGI handlers together to have just "Handler" (or
"HttpHandler") and "HttpRequest", with no subclasses.
I don't know if the Django community wants to keep support for mod_python now
that it's officially dead. If so, I would suggest using a mod_python<->WSGI
wrapper, which I believe is better than having a separate handler:
1.- There would be only one type of request, which means:
- It'd be less likely for a Django application to behave differently on
mod_python vs mod_wsgi; or mod_python vs FastCGI; etc.
- All the new WSGI-related features I am implementing will be
automatically available under mod_python.
2.- It'd be possible to use WSGI middleware under mod_python.
There would be three ways to keep support for mod_python with the two
advantages above:
1.- Adapting the existing code the mod_python handler and also applying the
changes I proposed in the patch for ticket #8927.
2.- Copying the following module (Public Domain) into Django:
http://www.aminus.net/browser/modpython_gateway.py
3.- Not adding mod_python support in Django itself, but instead recommend
using a mod_python<->WSGI wrapper like paste.modwsgi:
http://bitbucket.org/ianb/paste/src/tip/paste/modpython.py
I am willing to provide a patch for this and I wouldn't mind using any of
these three approaches. But if you ask me, I think no one should be using
mod_python at this point and therefore I'd suggest dropping support for
mod_python (the 3rd option):
http://blog.dscpl.com.au/2010/05/modpython-project-soon-to-be-officially.html
http://blog.dscpl.com.au/2010/06/modpython-project-is-now-officially.html
To sum up, I'm proposing two things:
1.- Making the WSGI handler the only handler.
2.- If we want to keep mod_python support, use a mod_python<->WSGI wrapper.
What do you think?
PS: You may want to see the latest comments on Ticket #8927:
http://code.djangoproject.com/ticket/8927
--
Gustavo Narea <xri://=Gustavo>.
| Tech blog: =Gustavo/(+blog)/tech ~ About me: =Gustavo/about |
Robert Coup
On Wed, Jun 23, 2010 at 11:22 AM, Gustavo Narea <m...@gustavonarea.net> wrote:
>
> I'm going to work on some patches to improve WSGI support, and I found
> something that, if changed, could make my patches and django.core.handlers
> simpler... As well as make it possible to use WSGI middleware with Django
> under mod_python.
It seems like a tonne of work to *add* compatibility for something we
don't want people to use... if someone wants to use wsgi middleware
under mod-python, I don't see why Django should help that - go install
mod_wsgi!
I'd suggest that you add features to the WSGI handler/request and just
not support those features for people using the mod_python handler?
Then the compatibility work is just not making sure you don't break
mod-python.
Rob :)
Russell Keith-Magee
> To sum up, I'm proposing two things:
> 1.- Making the WSGI handler the only handler.
> 2.- If we want to keep mod_python support, use a mod_python<->WSGI wrapper.
>
> What do you think?
As noted in a separate thread -- we're looking to deprecate
mod_python. The mod_python code will need to linger and remain
operational for a couple of releases, but I have no problem if you
ignore mod_python for the purposes of your changes.
Yours,
Russ Magee %-)
Gustavo Narea
On 23 June, 01:00, Russell Keith-Magee <russ...@keith-magee.com>
wrote:
Thanks.
Tom Evans
> Hello,
>
> I'm going to work on some patches to improve WSGI support, and I found
> something that, if changed, could make my patches and django.core.handlers
> simpler... As well as make it possible to use WSGI middleware with Django
> under mod_python.
>
>
> To sum up, I'm proposing two things:
> 1.- Making the WSGI handler the only handler.
> 2.- If we want to keep mod_python support, use a mod_python<->WSGI wrapper.
>
What about FastCGI?
Cheers
Tom
Russell Keith-Magee
FastCGI is a server interface, not a handler interface. If you dig
into the internals, the FastCGI interface uses WSGI to serve pages.
Yours,
Russ Magee %-)
Gert Van Gool
Mobile: +32 498725202
Web: http://gert.selentic.net
Yours,
Russ Magee %-)
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Russell Keith-Magee
> So in theory, if you change the mod_python handler to one of the projects
> mentioned (like paste.modwsgi).
> mod_python is "promoted" to the same status as FastCGI?
I'm not sure I understand your question.
I suppose the approach of using paste.modwsgi to deploy Django in a
mod_python environment could be considered analogous to the way
FastCGI works. However, that certainly won't be the officially
endorsed deployment approach. The officially endorsed approach will be
"use (mod_)wsgi".
Yours,
Russ Magee %-)