<div dir="ltr"><div dir="ltr">Hi everyone,<div><br></div><div>I'd like to breach the topic of standardising an asynchronous successor to WSGI - specifically, the ASGI specification I and a group of other Python web developers have been refining over the past couple of years (you can read more at <a href="https://asgi.readthedocs.io/en/latest/">https://asgi.readthedocs.io/en/latest/</a>).</div><div><br></div><div>I'm unsure of the best approach to take for this, given a couple of factors:</div><div><br></div><div> - Web SIG has been basically dead for at least two years and several maintainers I know unsubscribed from it last time as things got toxic. It appears to not be a good place to start this discussion, but maybe it can be revived?</div><div><br></div><div> - The specification as I would propose it is two or three parts - an overall interface for asynchronous servers to talk to applications and then a separate specification(s) of how to transport HTTP and WebSockets over that. Would this be multiple PEPs?</div><div><br></div><div>I'd appreciate advice from you all on these questions as well as what you think the best way to even approach something like "let's add a WSGI successor" is.</div><div><br></div><div>My initial approach was to go away and prove something in real-world use and across a variety of frameworks, and we seem to have got to that point, and so now I would like to start making it more official.</div><div><br></div><div>I'm more than ready to take the specification we have and start prepping it to land into the PEP repo for further discussion, but I wanted to check in here first before jumping the gun (and besides, there's already plenty of specs, write ups, and reference code to discuss the merits of this).</div><div><br></div><div>Andrew</div></div></div>