[mod_python] mod_python and other web server that not apache

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?

Regards, Clodoaldo Pinto Neto