[Chicago] Status of wsgi

[Garrett Smith]

On Thu, Oct 11, 2012 at 1:01 PM, Jordan Bettis <jordanb at hafd.org> wrote:
> 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.

It's quite possible -- but that's app design decision (probably wants
to be event driven, but "business logic" type events, not IO).

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

Yes, you're right. I get the impression reading PEP 444 that "async"
is nothing more than supporting a zero arity callable from the WSGI
app. Still, it says "async" very clearly :)

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

Aye. And as I'm re-reading Phillip Eby's excellent PEP 333, it's clear
that WSGI had to be as simple as possible to get any traction in the
first place. An event driven response model would make the interface
quite a bit more complex.

Garrett