[Web-SIG] PEP 444 / WSGI 2 Async

[Alex Grönholm]

08.01.2011 07:09, P.J. Eby kirjoitti:
> 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]".
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 at python.org
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe: 
> http://mail.python.org/mailman/options/web-sig/alex.gronholm%40nextday.fi