[Web-SIG] WSGI 2.0
robinbryce at gmail.com
Sat Oct 6 14:23:49 CEST 2007
On 06/10/2007, Manlio Perillo <manlio_perillo at libero.it> wrote:
> Phillip J. Eby ha scritto:
> > At 10:13 PM 10/5/2007 +0100, Robin Bryce wrote:
> >> That's to much chicken/egg for my tastes. All you are really saying is
> >> that the CGI model covers the majority of 'common' use cases. I don't
> >> know of anyone who would disagree with this. But as things stand all
> >> wsgi-ish implementations which aim to support async/sync are consigned
> >> to the dust bin of 'non conformant'. This acts as a strong
> >> disincentive to experiment and innovate.
> >> If, for clear technical reasons, nothing can be done so support mixing
> >> async aware and synchronous applications in WSGI 2.0, then so it goes.
> I don't see the reason to mix async and sync applications, in the same
> way that it is not possible to mix a thread unsafe application with a
> threaded server.
> WSGI should just *allow* asynchronous applications and middlewares to to
> their job.
> As an example, the WSGI write callable cannot be implemented in a
> conforming way in Nginx.
> However, if we can allow the write callable to raise an EAGAIN exception
> when the buffer cannot be written to the socket, with the requirement
> that the WSGI application, in this case, MUST return control to the
> server (yielding an empty string as an example), then the write callable
> can be implemented.
> > [...]
> > If we were going to try to implement an asynchronous WSGI, what we would
> > *really* need to do is discard the app_iter and make write() the
> > standard way of sending the body. This would let us implement a CPS
> > (continuation-passing style) API.
> But isn't this possible just using a generator?
> > We would also have to change the
> > input stream so that instead of reading from it, we instead passed it
> > functions to be called when input was available,
> Another possible solution is that reading from input is allowed to raise
> an EAGAIN exception, like in the previous example.
> > [...]
> Regards Manlio Perilo
> Web-SIG mailing list
> Web-SIG at python.org
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe: http://mail.python.org/mailman/options/web-sig/robinbryce%40gmail.com
More information about the Web-SIG