[Chicago] Status of wsgi

[Jordan Bettis]

On 10/11/2012 10:42 AM, Garrett Smith wrote:
>>> 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.

I did not know that about Erlang. It seems like I asked Chris Webber how
his foray into Erlang was going and he told me he was up to his eyeballs
in callbacks.


> 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.

That's good to hear that they made that change. Although.. I think I'm
missing something. If the application returns a callback then the server
doesn't know when it's ready. So it just has to poll the callback until
it returns something other than None, right?

At any rate, like someone said earlier up in the thread, asynchronous
server responses are a pretty slim edge case for how web applications
are currently written. For the vast majority of applications, the
receive-a-request-immediately-generate-a-response cycle is perfectly
sufficient, and any long-running jobs they have (like sending an email)
are also deferrable and can be farmed out to cron or whatever. So to the
extent that python has a problem with async I think it's due to an
insufficient supply of giveafuck.