[Web-SIG] WSGI and start_response

[Manlio Perillo]

P.J. Eby ha scritto:
> At 04:59 PM 4/8/2010 +0200, Manlio Perillo wrote:
> [...]
>> There should be a sample WSGI 2.0 implementation for CGI, and a sample
>> WSGI 1.0 -> 2.0 adapter.
>>
>> This adapter should be able to support the coroutine example,
>> > http://paste.pocoo.org/show/199202/
>> but I would like to test.
>>
>> write callable, as far as I know, can not be implemented.
> 
> Implementing it requires greenlets or threads, but it's implementable. 
> See:
> 
> http://mail.python.org/pipermail/web-sig/2009-September/003986.html
> 

Right.
In fact, in the example I posted, I implemented the write callable using
greenlets (although the implementation is different).

> (Btw, I've noticed that this early sketch of mine doesn't support the
> case where an application is a generator, because start_response won't
> have been called when the application returns.  This can be fixed, but
> it requires the addition of a wrapper class and a few other annoying
> details.  It also doesn't support exc_info properly, so it's still a
> ways from being a correct WSGI 1 server implementation.  Getting rid of
> all these little variations, though, is the goal of having a WSGI 2 -
> it's difficult to write *any* middleware to be completely WSGI 1
> compliant.)
> 

I agree that this is a good goal.
However I don't like the idea of losing support for some features.

With WSGI 2.0 we will end up with:

- WSGI 1.0, a full featured protocol, but with hard to implement
  middlewares
- WSGI 2.0, a simple protocol, with more easy to implement middlewares
  but without support for some "advanced" applications


Both WSGI 1.0 can be implemented on top of WSGI 2.0, and WSGI 2.0 on top
of WSGI 1.0.

The latter should be more "easy" to implement.


I would like to have a WSGI 1.1 specification without the write
callable, and a *standard* adapter that will expose a more simple API
(like WSGI 2.0) so that applications and middlewares can be implemented
using this simple API but you still have the full featured API.

This is important, IMHO.
Because with the next version of WSGI, there will be also support for
Python 3.x.
And if the next version will not have support for the start_response
function, applications that needs Python 3.x and want to use "advance
features" will not be able to rely a standard procotol.



Regards   Manlio