[Chicago] Status of wsgi

[Garrett Smith]

On Thu, Oct 11, 2012 at 9:48 AM, Garrett Smith <g at rre.tt> wrote:
> On Wed, Oct 10, 2012 at 3:43 PM, Jordan Bettis <jordanb at hafd.org> wrote:
>> On 10/09/2012 12:09 PM, Garrett Smith wrote:
>>> It's been a number of years now since I've built web stuff in Python
>>> (forgive me) but last I checked, wsgi was still the dominant force in
>>> Python land for anything web.
>>>
>>> With Python 3, web sockets, crazed fixation on async socket servers,
>>> etc. I'm wondering if that's still the case. Has wsgi been able to
>>> keep up with the latest trends, or is it falling over? Is there
>>> another standard in Python land that shows more promise or growth
>>> trajectory?
>>>
>>> I ask because I'm researching some options for a similar spec for the
>>> Erlang community -- and I'd like to catalog the good and bad of
>>> Python's (much more mature) web ecosystem.
>>
>> WSGI doesn't support async and for that reason neither tornado nor
>> twisted use it. Tornado has a wsgi-client request handler, which is nice
>> if you want to have a site that is built on wsgi, but need to extend it
>> to handle some requests asynchronously.
>>
>> WSGI is dominant insofar as the dominant web frameworks (django
>> especially) use it. And there hasn't been a lot of pressure for them to
>> support async.
>>
>> Given what I know about Erlang, WSGI would probably not be a good model
>> for an erlang-based web gateway interface. Maybe look at twistedweb?
>
> While Erlang supports "async" topics (this is an imprecise of language
> btw :) it's not predicated on event reactor + callbacks the way
> Twister and co are. Programming is quite sequential (it's a functional
> language) and WSGI, esp WSGI 2 which drops the side-effecty
> start_response function, is an excellent fit.
>
> Btw, this is one of the problems that makes Python "async" ecosystem
> so dysfunctional -- there's no standardization on a common
> library/protocol, so each of these servers lives in its own world.
>
> There are a number of WSGI interfaces to async Python web servers, so
> I wouldn't say that the protocol doesn't support it. IIRC there are
> some pretty clever hacks using WSGI environ + Python co-routines to
> facilitate Frankenstein style apps :)

Reading up on PEP 444 (ostensibly just WSGI for Python 3 compatibility):

http://www.python.org/dev/peps/pep-0444

It looks like there's now explicit support for providing "async" responses:

 | When called by the server, the application object must return a tuple
 | yielding three elements: status, headers and body, or, if supported
 | by an async server, an argumentless callable which either returns
 | None or a tuple of those three elements.

I don't know if anyone's using this effectively though.

Garrett