08.01.2011 07:09, P.J. Eby kirjoitti:
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]".
How do you suppose common async middleware could be implemented without
a common async API? Today we have plenty of WSGI middleware, which would
not be possible without a common API. You would have to make separate
interfaces for every major framework and separately test against each of
them instead of having a reasonable expectation that it will work
uniformly across compliant frameworks. I would really love to see common
middleware components that are usable on twisted, tornado etc. without
modifications.
You seem to be under the impression that asynchronous applications only
have some specialized uses. Asynchronous applications are no more
limited in scope than synchronous ones are. It's just an alternative
programming paradigm that has the potential of squeezing more
performance out of a server. Note that I am in now way insisting that
PEP 444 require async support; I'm only exploring that possibility. If
we cannot figure out a way to make it easy for implementors to support,
then I will push for a separate specification.
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.
What exactly does "run this in a future after the request" mean? There
seems to be some terminology confusion here.
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.
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/alex.gronholm%40nextday.fi
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
