[mod_python] mod_python and other web server that not apache

On 24/11/2007, Clodoaldo <clodoaldo.pinto.neto at gmail.com> wrote:
> 2007/11/22, Graham Dumpleton <graham.dumpleton at gmail.com>:
> > On 22/11/2007, EdgardCosta <edgardalvescosta at gmail.com> wrote:
> > > Hi
> > >
> > > I receved a question in other maillist that anserwer if the python can
> > > run in other webserver whitout be the apache.
> > > I think that the apache is the only one. Or Iam wrong?
> >
> > Options for running web applications written in Python are as follows:
> >
> > 1. Web server is actually written in Python and Python web application
> > sits on top of that in the same process. This web server may be the
> > direct public facing web server, or may be hosted behind another web
> > server such as Apache, lighttpd or nginx, with requests being proxied
> > from the front end web server using the corresponding mod_proxy like
> > module for the front end web server. There are various web servers
> > available written in Python.
> >
> > 2. Python web application runs within an instance of the Python
> > interpreter which runs embedded within a web server which is written
> > in C. This option only currently exists for Apache. Two Apache modules
> > exist for this. These are mod_python and mod_wsgi
> > (http://www.modwsgi.org).
> >
> > You obviously know about mod_python. Whereas mod_python provides its
> > own specific APIs and thus a web application written direct for that
> > isn't portable to any other hosting option, in mod_wsgi the Python
> > WSGI standard is used. An application written to the Python WSGI
> > standard is portable to any of the options listed here. There are even
> > workable, although not perfect, WSGI adapters for mod_python.
> >
> > 3. Python web application runs within a daemon process separate to the
> > web server and requests are proxied from the web server to this daemon
> > process. The web server is written in C. Rather than HTTP protocol
> > being used as in option 1 above, an alternate protocol is used. There
> > are actually a number of different variations on this theme.
> >
> > 3a. In the case of the mod_wsgi module, it supports a daemon mode in
> > addition to embedded mode. It uses it own internal protocol for
> > proxying data. This is done as mod_wsgi daemon processes are a direct
> > fork of the Apache child processes and so they are tightly coupled.
> >
> > 3b. Next are solutions based on FASTGCI protocol for proxying of
> > request to daemon process. The daemon process can either be started
> > separately, or be forked from Apache, but then a distinct application
> > executed. The application run in this case would actually be the
> > Python executable. A module such as flup would be used which
> > understands the FASTCGI protocol thereby allowing communication with
> > the web server. Web applications may be written direct to flup
> > interface to FASTCGI protocol, or written to WSGI standard and a
> > flup/WSGI adapter used.
> >
> > 3c. Like 3b, but SCGI protocol used instead. The flup package would
> > still be used as it also supports SCGI.
> >
> > 3d. Like 3b, but AJP protocol used instead. The flup package would
> > still be used as it also supports AJP.
> >
> > Although 3a, and I think 3c and 3d are specific to Apache, the FASTCGI
> > protocol described is also supported by lighttpd and nginx.
> >
> > If you want the most portable option for writing a Python web
> > application, write it to the WSGI standard or use an existing
> > framework which supports that standard. That way you can use any of
> > the above options.
>
> Graham,
>
> This is the most comprehensive and at the same time the most concise
> listing of the available technologies to deploy python on the web i
> have read.
>
> I was wondering if it would be a good idea to create a Wikipedia
> article with your text. Would you care? What do you think?

I'd rather you didn't. It hardly does the topic justice and if
something is done I'd prefer it be done properly.

I have floated an idea a number of times in different forums of trying
to get a group of people together to properly document, at least for
WSGI, what all the hosting solutions are that are available. This
would include general descriptions, setup instructions for simple
cases and the pros and cons of each as well as comparative benchmarks
for a range of different scenarios with the same WSGI application code
used for each hosting solution. The idea is so that there is some
decent information on which to base decisions of what to use, rather
than people relying on the incomplete, or misinformed opinion that is
out there.

Needless to say, no one was interested and I don't have time myself for it now.

Graham