Re: [Web-SIG] Draft 2: WSGI Response Upgrade Bridging
On 13 October 2014 16:59, PJ Eby p...@telecommunity.com wrote: On Sun, Oct 12, 2014 at 6:47 PM, Robert Collins robe...@robertcollins.net wrote: FWIW I'm totally fine with you bringing together that PEP - as you say its complementary to what I'm focused on (I believe I even suggested you might want to do that). Did you have any feedback on the proposal itself? I'm particularly counting on you to tell me if I've horribly misunderstood something important about the use cases or the requirements for the protocols themselves. Not yet. Really just got back to stuff today. Rather than digging a hole for myself by commenting until I've absorbed it, let me do that and then I'll comment. :) I think that the upgrade model I've presented will enable you to happily design completely new API paradigms without having to figure out how to tunnel them through a maze of WSGI middleware, with the exception of having reasonable ways to present the incoming request as a WSGI request. But if I've missed something there, please let me know. Sure will. As I said earlier on in our thread, I'm not convinced that presenting new things as WSGI1 requests makes sense. I understand your arguments about adoption, but as I understand it WSGI itself started with nothing implementing it, and yet its now a very common lingua franca. So - I'd like to defer thinking too hard about the migration path, other than ensuring that its possible - and your draft may well be instrumental in some of the conversion paths needed. More once I've absorbed it. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Draft 2: WSGI Response Upgrade Bridging
On 13 October 2014 17:12, Benoit Chesneau bchesn...@gmail.com wrote: ... OK, So I should probably know you, but I can't recollect right now what you do or write. Its not clear to me who you were replying to. If Graham - Graham is the mod_wsgi maintainer, which I'm sure you've heard of - he, like you is one of the actors we need engaged and behind this effort. And PJE was the original WSGI maintainer :). Anyway I find it really disturbing the way you're actually acting and try to push your ideas based on private feedback coming from unknown or choosing who should be a reference. That certainly not the right way to have all actors on the table. Because if we go for a new WSGI spec, you certainly want it. And I am speaking as one of these actors. As I said when folk talked about going private in the first thread on this, I'm willing to discuss anything publically or privately - I can't tell folk where they will be comfortable discussing things. But I'm going to do *my* work on this in public, because I think that is essential to get broad consensus. In my opinion, if we want to go further we should first define what are the problem we want to solve, and then get the feedback from all the actors around: I think I've been fairly clear about the problem *I* want to solve. We want to create a clean common API for applications and middleware written in a post HTTP/2 world - where single servers may accept up to all three of HTTP/1.x, HTTP/2 and Websocket connections, and applications and middleware want to be able to take advantage of HTTP/2 and websockets when available, but also degrade gracefully. We also want to ensure that there is a graceful incremental path to adoption of the new API, including Python 2.7 support, and shims to enable existing WSGI apps/middleware/servers to respectively be contained, contain-or-be-contained and contain, things written to this new API. We want a clean, fast and approachable API, and we want to ensure that its no less friendly to work with than WSGI, for all that it will expose much more functionality. - framweorks authors I reached out to a number of such authors directly. I encourage you to do the same. - libraries author Ditto and - server authors Ditto :). If you don't have all actors around and majors are missing, there is probably no point to continue. I do think the idea of having a repository to collect it with people arbitrating the discussions on them on the mailing is a good way to go further. Now I think we are still missing of a clear definition of the problem. This is from what we should start instead of starting by giving our philosophy on how the problem should be solved. Here's my definition of some of the problems: A - there is no common spec equivalent to WSGI that permits writing server side code that takes advantage of HTTP/2. There's *a* http/2 server out there which one can write code for, but that code is either specific to that servers plumbing, or plain WSGI and misses the HTTP/2 goodness. B - WSGI has some oddness and overheads due in large part to the situation it was aiming to fix (which it broadly did) that perhaps we can now come together to fix. C - Support for chunked uploads, comet, bosh and websockets is effectively impossible within WSGI - one ends up writing server specific code, and being tied to a single server - even though multiple servers support (some of) those things. This defeats the point of WSGI IMNSHO: its not that WSGI is broken or anything, its just that we're once again writing all our generic middleware in server-specific fashions. Because the world has moved on and we haven't. I think A and C are crucial if we want to re-instate a lingua franca for the current web, in Python. I'd like to address B, because we can. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Draft 2: WSGI Response Upgrade Bridging
On Mon, Oct 13, 2014 at 11:52 AM, Robert Collins robe...@robertcollins.net wrote: On 13 October 2014 17:12, Benoit Chesneau bchesn...@gmail.com wrote: ... OK, So I should probably know you, but I can't recollect right now what you do or write. Its not clear to me who you were replying to. I answered at the bottom of the thread so to PJE. Anyway I find it really disturbing the way you're actually acting and try to push your ideas based on private feedback coming from unknown or choosing who should be a reference. That certainly not the right way to have all actors on the table. Because if we go for a new WSGI spec, you certainly want it. And I am speaking as one of these actors. As I said when folk talked about going private in the first thread on this, I'm willing to discuss anything publically or privately - I can't tell folk where they will be comfortable discussing things. But I'm going to do *my* work on this in public, because I think that is essential to get broad consensus. In my opinion, if we want to go further we should first define what are the problem we want to solve, and then get the feedback from all the actors around: I think I've been fairly clear about the problem *I* want to solve. We want to create a clean common API for applications and middleware written in a post HTTP/2 world - where single servers may accept up to all three of HTTP/1.x, HTTP/2 and Websocket connections, and applications and middleware want to be able to take advantage of HTTP/2 and websockets when available, but also degrade gracefully. We also want to ensure that there is a graceful incremental path to adoption of the new API, including Python 2.7 support, and shims to enable existing WSGI apps/middleware/servers to respectively be contained, contain-or-be-contained and contain, things written to this new API. We want a clean, fast and approachable API, and we want to ensure that its no less friendly to work with than WSGI, for all that it will expose much more functionality. By which problem we need to solve, I mean we need to identify clearly what are the problem not solved by the current spec. And see why, and how it is actually solved in the python world. we need to clearly identify these issues and make sure we have a comprehensive view of them. - framweorks authors I reached out to a number of such authors directly. I encourage you to do the same. I could do that eventually if we are all agree on the process. - libraries author Ditto and - server authors Ditto :). If you don't have all actors around and majors are missing, there is probably no point to continue. I do think the idea of having a repository to collect it with people arbitrating the discussions on them on the mailing is a good way to go further. Now I think we are still missing of a clear definition of the problem. This is from what we should start instead of starting by giving our philosophy on how the problem should be solved. Here's my definition of some of the problems: A - there is no common spec equivalent to WSGI that permits writing server side code that takes advantage of HTTP/2. There's *a* http/2 server out there which one can write code for, but that code is either specific to that servers plumbing, or plain WSGI and misses the HTTP/2 goodness. B - WSGI has some oddness and overheads due in large part to the situation it was aiming to fix (which it broadly did) that perhaps we can now come together to fix. C - Support for chunked uploads, comet, bosh and websockets is effectively impossible within WSGI - one ends up writing server specific code, and being tied to a single server - even though multiple servers support (some of) those things. This defeats the point of WSGI IMNSHO: its not that WSGI is broken or anything, its just that we're once again writing all our generic middleware in server-specific fashions. Because the world has moved on and we haven't. Chunkedn upload is possible and already handled with Gunicorn. But there is no standard for that. For C I would separate it from the rest. This a different discussion and imo not everything can be achieved at the same time. Maybe we should start first by fixing them, then go for the next step anyway. So the transition could be incremental in servers and frameworks and actually fix the current spec. For A (And C), i think we should keep the new specification enough agnostic. Especially since HTTP 2 is not yet completely out. - benoit I ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Draft 2: WSGI Response Upgrade Bridging
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/13/2014 12:12 AM, Benoit Chesneau wrote: So I should probably know you, but I can't recollect right now what you do or write. Seriously? On *this* sig? PJE was the author of PEP 333, defining the WSGI 1.0 spec. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlQ8jEgACgkQ+gerLs4ltQ6VGgCg3UUBwHClvJv3dtHP22Z1EVBn wpgAn0oA3pMAgLY0lqExyZ2zvsQfnteY =o+WJ -END PGP SIGNATURE- ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Draft 2: WSGI Response Upgrade Bridging
On 14 October 2014 01:18, Benoit Chesneau bchesn...@gmail.com wrote: C - Support for chunked uploads, comet, bosh and websockets is effectively impossible within WSGI - one ends up writing server specific code, and being tied to a single server - even though multiple servers support (some of) those things. This defeats the point of WSGI IMNSHO: its not that WSGI is broken or anything, its just that we're once again writing all our generic middleware in server-specific fashions. Because the world has moved on and we haven't. Chunkedn upload is possible and already handled with Gunicorn. But there is no standard for that. Right. Thus we need one. For C I would separate it from the rest. This a different discussion and imo not everything can be achieved at the same time. Maybe we should start first by fixing them, then go for the next step anyway. So the transition could be incremental in servers and frameworks and actually fix the current spec. What makes C a different discussion? For A (And C), i think we should keep the new specification enough agnostic. Especially since HTTP 2 is not yet completely out. HTTP/2 is in last call stage: it will be entirely finished by the time we get through whatever process we have here. What do you want to see changed in the process I'm following? -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Draft 2: WSGI Response Upgrade Bridging
On 11 October 2014 08:10, PJ Eby p...@telecommunity.com wrote: On Fri, Oct 10, 2014 at 8:56 AM, Graham Dumpleton graham.dumple...@gmail.com wrote: So PJE, please step back and do not go rushing out to create a PEP. That is the worst thing you could do at this point and will only serve to deter people from the community contributing and so stifle proper discussion about this whole topic. Huh? Have you *read* the PEP? The entire point of it is to provide a basis for *experimenting* with new standards, not to stifle discussion of them. It's not even an *API*, for heavens' sake. It's just a description of how to upgrade to new standards from within existing WSGI frameworks, without needing to tunnel responses and without breaking subrequest middleware. FWIW I'm totally fine with you bringing together that PEP - as you say its complementary to what I'm focused on (I believe I even suggested you might want to do that). -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Draft 2: WSGI Response Upgrade Bridging
On 11 October 2014 01:56, Graham Dumpleton graham.dumple...@gmail.com wrote: I've pushed up https://github.com/python-web-sig/wsgi-ng/commit/df51d7d6fd4faa4efbe397fda2c323932f967020 which hopefully addresses the process and clarity concerns you expressed. (If not please help me tweak it appropriately). -Rob ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Draft 2: WSGI Response Upgrade Bridging
On Sun, Oct 12, 2014 at 6:47 PM, Robert Collins robe...@robertcollins.net wrote: FWIW I'm totally fine with you bringing together that PEP - as you say its complementary to what I'm focused on (I believe I even suggested you might want to do that). Did you have any feedback on the proposal itself? I'm particularly counting on you to tell me if I've horribly misunderstood something important about the use cases or the requirements for the protocols themselves. I think that the upgrade model I've presented will enable you to happily design completely new API paradigms without having to figure out how to tunnel them through a maze of WSGI middleware, with the exception of having reasonable ways to present the incoming request as a WSGI request. But if I've missed something there, please let me know. ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Draft 2: WSGI Response Upgrade Bridging
On Fri, Oct 10, 2014 at 9:10 PM, PJ Eby p...@telecommunity.com wrote: On Fri, Oct 10, 2014 at 8:56 AM, Graham Dumpleton graham.dumple...@gmail.com wrote: So PJE, please step back and do not go rushing out to create a PEP. That is the worst thing you could do at this point and will only serve to deter people from the community contributing and so stifle proper discussion about this whole topic. Huh? Have you *read* the PEP? The entire point of it is to provide a basis for *experimenting* with new standards, not to stifle discussion of them. It's not even an *API*, for heavens' sake. It's just a description of how to upgrade to new standards from within existing WSGI frameworks, without needing to tunnel responses and without breaking subrequest middleware. IOW, it's a WSGI *1.0* server extension protocol, and a fairly *minor* one at that. (Indeed, it's little more than an enhanced variation of wsgi.file_wrapper!) It's not any sort of competitor or alternative to what Robert's working on; it's a *stepping stone* for what Robert's working on. In early discussion with Robert -- both here and on github -- it became apparent to me that restricting post-WSGI specifications to what can be achieved in WSGI 1 tunneling is a bad idea. So I've created a *bridging* specification, that allows post-WSGI APIs to be accessed from within WSGI-based apps and frameworks. That's *all*. All of the things you've mentioned as being in scope for discussion, are *still* in scope for discussion. All *this* proposal does is show how those things could be *accessed*, *today*, from inside existing web apps and frameworks, once those new APIs exist. You have no more experience or mandate to be specifying a standard for this than anyone else. If by this you're referring to HTTP/2 or some other new post-WSGI API, then I agree with you. But that's not what the PEP is about. By creating a PEP though that gets perceived by many as meaning the discussion is over. This is exactly what you did for PEP and which caused previous discussion about improving WSGI to get shutdown. That's an interesting perspective, but I don't see how it can be reconciled with the facts. First off, I didn't write a new PEP; I wrote up some of *your* proposed clarifications for Python 3 as WSGI 1.0.1, which was intended to add new clarifying text to PEP 333, *not* to create a new PEP. It was *Guido* who said it must be a new PEP, as you will see here: https://mail.python.org/pipermail/web-sig/2010-September/004691.html and here (where he even says, Don't see this as a new spec. See it as a procedural issue.): https://mail.python.org/pipermail/web-sig/2010-September/004694.html Second, I didn't make anybody stop discussing alternatives for moving things forward. Nobody *ever* said to stop working on a version 2 or even 1.1, certainly not me. See for example, this message, where I agreed with Ian's POV that there was room for both PEP 333 fixes *and* continued work on PEP 444: https://mail.python.org/pipermail/web-sig/2010-September/004662.html Third, and finally, as far as I can tell from the record of the discussion back then, it was you -- and *only* you -- who suggested that the acceptance of PEP meant the discussion was *over*. Indeed, on your blog you actually pushed back at Alice for bringing up more PEP 444 discussion! Nonetheless, discussion of PEP 444 and async APIs and such proceeded well past the introduction of PEP , even without its original authors' participation. And, ironically enough, your posts show up in that discussion, bemoaning that Alice (the new PEP 444 champion) was creating confusion by calling that proposal WSGI 2.0! The result was that the only thing that really got addressed in PEP was Python 3 compatibility and a lot of the other bits of the WSGI specification which are poorly defined, contradictory or restrictive and which cause WSGI server and application developers pain never got addressed. If that prior discussion hadn't been shutdown in that way, we could have been using a better defined and improved WSGI years ago already. Those things didn't get addressed because *you* didn't take up the lead -- a lead which I more than once mentioned you should take up. For example, as I said in https://mail.python.org/pipermail/web-sig/2010-September/004693.html : The full list of things Graham and others have asked for or recommended would indeed require a 1.1 version at minimum, and thus a new PEP. But I really don't want to start down that road right now, and therefore hope that I can talk Graham or some other poor soul into shepherding a 1.1 PEP instead. ;-) You didn't, and haven't, taken up that slack. What you've consistently done is mutter and grumble on the sidelines about how it's never going to happen and disclaim any responsibility for actually writing a proposal
Re: [Web-SIG] Draft 2: WSGI Response Upgrade Bridging
On 07/10/2014, at 7:15 AM, PJ Eby p...@telecommunity.com wrote: As before, you can find a living HTML version of the draft in progress at: https://gist.github.com/pjeby/62e3892cd75257518eb0 (In addition to nice formatting, it also has a clickable table of contents.) After the next round of feedback, I plan to convert this to reST and get a PEP number assigned -- assuming nobody comes up with a killer problem that sends me back to the drawing board, of course. ;-) For those who were not aware, I personally haven't commented as yet on this discussion because I have been on a holiday for the last few weeks and I wasn't going to allow a discussion about this to ruin my holiday. I haven't caught up yet on all the discussion, but it is sad to say that it has headed down a direction exactly as a I warned Robert Collins in private discussions would likely happen, with certain people trying to rush things to push their own specific idea for how things should be done, with the risk that that will dominate the agenda and so push Robert out of the way as far as trying to coordinate this as a community effort where anyone could feel confident about providing input with the result then also being a community effort. So PJE, please step back and do not go rushing out to create a PEP. That is the worst thing you could do at this point and will only serve to deter people from the community contributing and so stifle proper discussion about this whole topic. You have no more experience or mandate to be specifying a standard for this than anyone else. By creating a PEP though that gets perceived by many as meaning the discussion is over. This is exactly what you did for PEP and which caused previous discussion about improving WSGI to get shutdown. The result was that the only thing that really got addressed in PEP was Python 3 compatibility and a lot of the other bits of the WSGI specification which are poorly defined, contradictory or restrictive and which cause WSGI server and application developers pain never got addressed. If that prior discussion hadn't been shutdown in that way, we could have been using a better defined and improved WSGI years ago already. Robert has stuck his neck out to try and bring various parties together to work on this where anyone who has an opinion or idea can raise them so we as a community can all together come up with something which is workable for both server implementers and web application developers. Robert even setup a github repo specifically as a place to bring together all those ideas and described how people can add stuff there. For whatever personal reason you have decided to ignore that repo Robert set up and decided to go alone. If you have an issue with the way the repo was structured which didn't make it easy for you to contribute your work into it, then work with Robert to address that. Right now, that you have created your own separate space for writing up a specification which you are now trying to rush into a PEP comes across as you not really wanting to co-ordinate with Robert on this as a community effort with it instead appearing that you think you know better than anyone else and nothing anyone else says will be of value. In the face of that, it is hardly surprising that no one has really responded to what you have proposed. So slow down. This is not a race to see who can be the first to come out with a PEP and so dominate the discussion, it is meant to be a community effort. Robert. What I would suggest you do is reboot this whole effort. Go back and perhaps look at how the github repo you setup is structured and make it more obvious how anyone can add their work into it in separate areas of it as need be and not just as issues, if that isn't already clear enough. Document exactly what you want people to do as far as adding anything there. Find people who will work with you on making all this clearer and defining any process. The next step is to make a more definite statement about the timeline for this whole discussion. Specifically, give notice of a formal request for comment period and publicise it through any Python blogs of the PSF that might be able to be used, as well as through the different Python web communities. Also get prominent individuals in the Python WSGI and web community to also publicise the comment period. Set a specific date for the end of that comment period. There should be no rush on this and people should be given adequate time to respond. Most interested parties would only do this in their spare time and employers aren't going to allow them to waste their work time on it. So make the comment period something like 2 months from the date of announcing it. What can people comment on? They may want to comment on the process itself of how we get to the various specifications that may come out of this. They may want to comment on what should even be
Re: [Web-SIG] Draft 2: WSGI Response Upgrade Bridging
On 11 October 2014 01:56, Graham Dumpleton graham.dumple...@gmail.com wrote: ... Robert. What I would suggest you do is reboot this whole effort. Go back and perhaps look at how the github repo you setup is structured and make it more obvious how anyone can add their work into it in separate areas of it as need be and not just as issues, if that isn't already clear enough. Document exactly what you want people to do as far as adding anything there. Find people who will work with you on making all this clearer and defining any process. The next step is to make a more definite statement about the timeline for this whole discussion. Thanks for the process critique - I agree. I will put together such improvements in a little bit. I hadn't actually intended to go quiet - my intended next step was to collate the feedback we've had so far (and prompt you for some mod_wsgi orientated feedback). However, about 2 weeks back my Mum died, and that caused a rather big speed bump in the 'what I need to do' chore list, which still isn't over (but at least the crisis wise aspects are) They may want to comment on what should even be addressed in any revisions or extensions to the WSGI specification. In other words, don't limit this to just HTTP/2 and web sockets support. Allow people to raise their pet peeves about the existing WSGI specification so we can perhaps properly address them this time. The whole ASYNC issue with existing WSGI applications also should not be ruled out of scope as far as the comment period. Finally and hopefully, rather than people just complaining about things or giving wish lists, they will present properly fleshed out ideas for how to concretely solve ideas around ASYNC, HTTP/2 and web sockets. TBH I'd be fine with complaints and wish lists - got to start somewhere, and having a clear list of the places WSGI has not met needs would be excellent. One thing you could do, if you like, is to put a PR together for the wsgi-ng repo that adjusts README in the light of your feedback. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Draft 2: WSGI Response Upgrade Bridging
On Fri, Oct 10, 2014 at 8:56 AM, Graham Dumpleton graham.dumple...@gmail.com wrote: So PJE, please step back and do not go rushing out to create a PEP. That is the worst thing you could do at this point and will only serve to deter people from the community contributing and so stifle proper discussion about this whole topic. Huh? Have you *read* the PEP? The entire point of it is to provide a basis for *experimenting* with new standards, not to stifle discussion of them. It's not even an *API*, for heavens' sake. It's just a description of how to upgrade to new standards from within existing WSGI frameworks, without needing to tunnel responses and without breaking subrequest middleware. IOW, it's a WSGI *1.0* server extension protocol, and a fairly *minor* one at that. (Indeed, it's little more than an enhanced variation of wsgi.file_wrapper!) It's not any sort of competitor or alternative to what Robert's working on; it's a *stepping stone* for what Robert's working on. In early discussion with Robert -- both here and on github -- it became apparent to me that restricting post-WSGI specifications to what can be achieved in WSGI 1 tunneling is a bad idea. So I've created a *bridging* specification, that allows post-WSGI APIs to be accessed from within WSGI-based apps and frameworks. That's *all*. All of the things you've mentioned as being in scope for discussion, are *still* in scope for discussion. All *this* proposal does is show how those things could be *accessed*, *today*, from inside existing web apps and frameworks, once those new APIs exist. You have no more experience or mandate to be specifying a standard for this than anyone else. If by this you're referring to HTTP/2 or some other new post-WSGI API, then I agree with you. But that's not what the PEP is about. By creating a PEP though that gets perceived by many as meaning the discussion is over. This is exactly what you did for PEP and which caused previous discussion about improving WSGI to get shutdown. That's an interesting perspective, but I don't see how it can be reconciled with the facts. First off, I didn't write a new PEP; I wrote up some of *your* proposed clarifications for Python 3 as WSGI 1.0.1, which was intended to add new clarifying text to PEP 333, *not* to create a new PEP. It was *Guido* who said it must be a new PEP, as you will see here: https://mail.python.org/pipermail/web-sig/2010-September/004691.html and here (where he even says, Don't see this as a new spec. See it as a procedural issue.): https://mail.python.org/pipermail/web-sig/2010-September/004694.html Second, I didn't make anybody stop discussing alternatives for moving things forward. Nobody *ever* said to stop working on a version 2 or even 1.1, certainly not me. See for example, this message, where I agreed with Ian's POV that there was room for both PEP 333 fixes *and* continued work on PEP 444: https://mail.python.org/pipermail/web-sig/2010-September/004662.html Third, and finally, as far as I can tell from the record of the discussion back then, it was you -- and *only* you -- who suggested that the acceptance of PEP meant the discussion was *over*. Indeed, on your blog you actually pushed back at Alice for bringing up more PEP 444 discussion! Nonetheless, discussion of PEP 444 and async APIs and such proceeded well past the introduction of PEP , even without its original authors' participation. And, ironically enough, your posts show up in that discussion, bemoaning that Alice (the new PEP 444 champion) was creating confusion by calling that proposal WSGI 2.0! The result was that the only thing that really got addressed in PEP was Python 3 compatibility and a lot of the other bits of the WSGI specification which are poorly defined, contradictory or restrictive and which cause WSGI server and application developers pain never got addressed. If that prior discussion hadn't been shutdown in that way, we could have been using a better defined and improved WSGI years ago already. Those things didn't get addressed because *you* didn't take up the lead -- a lead which I more than once mentioned you should take up. For example, as I said in https://mail.python.org/pipermail/web-sig/2010-September/004693.html : The full list of things Graham and others have asked for or recommended would indeed require a 1.1 version at minimum, and thus a new PEP. But I really don't want to start down that road right now, and therefore hope that I can talk Graham or some other poor soul into shepherding a 1.1 PEP instead. ;-) You didn't, and haven't, taken up that slack. What you've consistently done is mutter and grumble on the sidelines about how it's never going to happen and disclaim any responsibility for actually writing a proposal because it's never going to go anywhere -- thereby *ensuring* that it's never going to go anywhere. (And one key reason I wrote the WSGI-RUB PEP is that I
