[Web-SIG] WSGI 2.0

[Graham Dumpleton]

On 07/10/2007, Manlio Perillo <manlio_perillo at libero.it> wrote:
> Graham Dumpleton ha scritto:
> > On 07/10/2007, Manlio Perillo <manlio_perillo at libero.it> wrote:
> >> Phillip J. Eby ha scritto:
> >>> At 11:04 AM 10/6/2007 +0200, Manlio Perillo wrote:
> >>>> As an example, the WSGI write callable cannot be implemented in a
> >>>> conforming way in Nginx.
> >>> ...unless you use a separate thread or process.
> >>>
> >> I'm insisting about asynchronous support in WSGI because
> >> Nginx *does not supports threads*.
> >>
> >> It has some thread support but it is *broken*.
> >> Even if in future the problems are solved, the threading model of Nginx
> >> *will break* many existing WSGI applications, since the WSGI iteration
> >> can be resumed in different threads.
> >>
> >> Of course, a WSGI application can use threads, but i think that it
> >> *needs* a wsgi.pause_output extension, for synchronization.
> >
> > I appreciate that you can't use the thread support in nginx, but what
> > I don't understand is why you can't utililise Python threading API (or
> > even POSIX threads) at the boundary between nginx and the interface
> > into the WSGI application, ie., in the WSGI adapter layer, so as to
> > emulate a synchronous style WSGI interface on top of the nginx event
> > driven layer.
>
> This is possible, but I think that it is better to offer a basic
> asynchronous support in WSGI, since in this way it is possible to build
> threading support in pure Python *and*, more important, this support is
> reusable by other implementations.
>
> > In other words you hide all the complexity of any queues
> > or other synchronisation mechanisms for communicating any data between
> > the two within the adapter. This way you do not need to expose an
> > asynchronous API to the WSGI application itself and existing WSGI code
> > can be used as is.
> >
>
> The Python threading support can be implemented as a "middleware", so it
> is trasparent to the WSGI application.
>
> Not sure if it can be called "middleware", however.

If providing support for synchronous WSGI by using an adapter is how
you would support that, then I think all your problems would be solved
very easily by not trying to push that asynchronous support be added
to WSGI itself. Instead, come up with your own independent
asynchronous Python API for nginx and call it something completely
different and not try and get it labeled as being WSGI in some way.

In other words, don't call your nginx module mod_wsgi but mod_pynginx
for example. Having done that, then offer as a separate package a
synchronous WSGI adapter for your mod_pynginx and clearly state that
although your module doesn't support WSGI directly, it does via the
separate WSGI adapter.

The reason you are getting so much push back here on this list is
because you are trying to turn WSGI in to something it isn't when
there isn't a need to as you could still provide support for the
current WSGI specification as is by taking the adapter approach
instead.

What you would end up with is not much different to how Apache
mod_python has a number of WSGI adapters available for it. In some
respects it would probably be more attractive to people for you to
provide a Python API for using nginx which better matches how nginx
works and allows the most performance to be gotten out of nginx for
Python applications, without binding yourself to WSGI. That way, if
people choose to work with your lower level API then they could and
write applications specifically for nginx in much the same way that
people write applications specifically for Apache using mod_python.

So, don't try and force your API to be WSGI, and at the same time
don't try and force the WSGI specification to change so you can call
what you are developing WSGI. Doing either is possibly only going to
limit the extent to which you could develop your nginx specific Python
API. You would be much better doing your API however you want, call it
something different, but then provide a WSGI adapter for those want to
run WSGI applications on top of it.

Graham