[Web-SIG] WSGI diagram

Graham Dumpleton graham.dumpleton at gmail.com
Tue Aug 21 02:19:52 CEST 2007

On 21/08/07, Cliff Wells <cliff at develix.com> wrote:
> On Tue, 2007-08-21 at 09:29 +1000, Graham Dumpleton wrote:
> > After dealing
> > with this email, found a message in my spam box from someone else
> > doing the same thing. This other persons name is Manlio Perillo. I
> > have pointed them to this discussion on Google groups, so maybe they
> > will explain what they are up to and all parties can get together. I
> > have already indicated to Manlio that I may be interested in providing
> > him with assistance in doing for Nginx HTTP what I have already done
> > in Apache mod_wsgi.
> Manlio is, in fact, the person I've been speaking of.   Your help would
> be terrific.  I'd actually meant to approach you about it before, but
> didn't know how interested you'd be in a Nginx port.

Because Apache mod_wsgi is to a degree quite wedded to the Apache
APIs, not sure I'd really call it a port, although there are certainly
things that could be learned from Apache mod_wsgi.

As I mentioned to Manlio one of the decisions that probably has to be
made early on is whether you want to try and support multiple Python
sub interpreters in a single process like mod_python and mod_wsgi do.
Although this can be useful in some circumstances it isn't always
practical as some third party extension modules will not work in
secondary Python sub interpreters.

Thus, to make it a lot simpler, you might only support use of the main
Python interpreter like would be the case if using pure Python web
server. Doing this would eliminate a lot of the complexity around
management of Python thread APIs and creation/destruction of Python
sub interpreters.

But then, if you cut things back and go for a simpler design, it is
arguable as to whether you may as well just use standard Python
program and pure Python web server behind a proxy, of flup behind
FASTCGI. Therefore comes down to what you want to achieve in doing it
and whether the benefit is really there and that it offers something
extra over these other existing approaches.


More information about the Web-SIG mailing list