[Web-SIG] PEP 444 / WSGI 2 Async

[P.J. Eby]

At 12:37 PM 1/7/2011 -0800, Alice Bevan­McGregor wrote:
>But is there really any problem with providing a unified method for 
>indication a suspend point?

Yes: a complexity burden that is paid by the many to serve the few -- 
or possibly non-existent.

I still haven't seen anything that suggests there is a large enough 
group of people who want a "portable" async API to justify 
inconveniencing everyone else in order to suit their needs, vs. 
simply having a different calling interface for that need.

If I could go back and change only ONE thing about WSGI 1, it would 
be the calling convention.  It was messed up from the start, 
specifically because I wasn't adamant enough about weighing the needs 
of the many enough against the needs of the few.  Only a few needed a 
push protocol (write()), and only a few even remotely cared about our 
minor nod to asynchrony (yielding empty strings to pause output).

If I'd been smart (or more to the point, prescient), I'd have just 
done a 3-tuple return value from the get-go, and said to hell with 
those other use cases, because everybody else is paying to carry a 
few people who aren't even going to use these features for real.  (As 
it happens, I thought write() would be needed in order to drive 
adoption, and it may well have been at one time.)

Anyway, with a new spec we have the benefit of hindsight: we know 
that, historically, nobody has actually cared enough to propose a 
full-blown async API who wasn't also trying to make their async 
server implementation work without needing threads.  Never in the 
history of the web-sig, AFAIK, has anyone come in and said, "hey, I 
want to have an async app that can run on any async framework."

Nobody blogs or twitters about how terrible it is that the async 
frameworks all have different APIs and that this makes their apps 
non-portable.  We see lots of complaints about not having a Python 3 
WSGI spec, but virtually none about WSGI being essentially synchronous.

I'm not saying there's zero audience for such a thing...  but then, 
at some point there was a non-zero audience for write() and for 
yielding empty strings.  ;-)

The big problem is this: if, as an app developer, you want this 
hypothetical portable async API, you either already have an app that 
is async or you don't.  If you do, then you already got married to 
some particular API and are happy with your choice -- or else you'd 
have bit the bullet and ported.

What you would not do, is come to the Web-SIG and ask for a spec to 
help you port, because you'd then *still have to port* to the new 
API...  unless of course you wanted it to look like the API you're 
already using...  in which case, why are you porting again, exactly?

Oh, you don't have an app...  okay, so *hypothetically*, if you had 
this API -- which, because you're not actually *using* an async API 
right now, you probably don't even know quite what you need -- 
hypothetically if you had this API you would write an app and then 
run it on multiple async frameworks...

See?  It just gets all the way to silly.  The only way you can 
actually get this far in the process seems to be if you are on the 
server side, thinking it would be really cool to make this thing 
because then surely you'll get users.

In practice, I can't imagine how you could write an app with 
substantial async functionality that was sanely portable across the 
major async frameworks, with the possible exception of the two that 
at least share some common code, paradigms, and API.  And even if you 
could, I can't imagine someone wanting to.

So far, you have yet to give a concrete example of an application 
that you personally (or anyone you know of) want to be able to run on 
two different servers.  You've spoken of hypothetical apps and 
hypothetical portability...  but not one concrete, "I want to run 
this under both Twisted and Eventlet" (or some other two 
frameworks/servers), "because of [actual, non-hypothetical rationale here]".

I don't deny that [actual non-hypothetical rationale] may exist 
somewhere, but until somebody shows up with a concrete case, I don't 
see a proposal getting much traction.  (The alternative would be if 
you pull a rabbit out of your hat and propose something that doesn't 
cost anybody anything to implement... but the fact that you're 
tossing the 3-tuple out in favor of yielding indicates you've got no 
such proposal ready at the present time.)

On the plus side, the "run this in a future after the request" 
concept has some legs, and I hope Timothy (or anybody) takes it and 
runs with it.  That has plenty of concrete use cases for portability 
-- every sufficiently-powerful web framework will want to either 
provide that feature, build other features on top of it, or both.

It's the "make the request itself async" part that's the hard sell 
here, and in need of some truly spectacular rationale in order to 
justify the ubiquitous costs it imposes.