[Web-SIG] PEP 444 / WSGI 2 Async
pje at telecommunity.com
Sat Jan 8 06:09:34 CET 2011
At 12:37 PM 1/7/2011 -0800, Alice BevanMcGregor 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.
More information about the Web-SIG