On 07/10/2007, Manlio Perillo <[EMAIL PROTECTED]> wrote: > Graham Dumpleton ha scritto: > > On 07/10/2007, Manlio Perillo <[EMAIL PROTECTED]> 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 _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
