-
Notifications
You must be signed in to change notification settings - Fork 205
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PEP, roadmap, future of ASGI specification, etc. #39
Comments
The ASGI spec was written as a pseudo-spec; I would like to take it further, but I haven't yet found the time to get my ducks in a row and talk to people who have worked on PEPs before to get some initial feedback (I am hoping PyCon US will let me get at least that part done). The other thing I was waiting for was a second implementation, but now that uvicorn supports ASGI I think that's a great step in that direction. |
@andrewgodwin Great! Thanks for all your hard work, looking forward to the future developments. :) If you have time and can think of anything that others or myself could do to assist you, please open an issue or reply in this thread if you'd like - I would be happy to help out wherever possible. |
@andrewgodwin Would you be open to creating a Read The Docs for hosting ASGI-related documentation? I am currently making attempts at creating compatibility examples for other projects, but I've run into some issues surrounding how to reference and present these examples. Here is an example case where this may be useful Pylons/pyramid_cookbook#198. I believe an authoritative source of information on ASGI in the RTD format would make it much easier to vet potential compatibility solutions and provide a reference for project maintainers should they decide to adopt ASGI. |
I'd definitely be willing to put one of those up - as that comment says, GitHub's RST rending is not the greatest. I'll see what I can knock out tonight. On the general PEP front, we had a mini "ASGI summit" with a few interested parties at PyCon US (Twisted, Flask, Trio, mod_wsgi and Django) and everyone generally agrees with the direction, and also thinks that going for a PEP is unnecessary right now as long as there's a clear spec everyone can adhere to. |
OK, I've made a |
Thanks for putting this up. |
I'm very interested in the future of the ASGI specification as a "spiritual successor to WSGI". Similarly to the sentiment expressed in #35, I think that the broader community using asyncio could benefit a lot from ASGI - not only by the utilities in this package, but through a more general adoption as a specification. With uvicorn recently becoming a viable ASGI server, I think there may be a need for a PEP document or some more formal guidance focusing on ASGI - particularly in regards to how it could/should be used outside of Django Channels.
I have been working on a micro-framework as well as various tools and examples to experiment with the spec and demonstrate the composability and potential uses of ASGI apps both with and without Django. ASGI apps are really flexible and quite enjoyable to develop, however the sources of information about ASGI seem to be, understandably, fragmented and inaccessible to those that aren't already familiar with Channels.
My questions at this point are:
Are there plans for a PEP document or any further ASGI-specific developments?
Is this the appropriate place to raise this issue? If not, where would this discussion be most useful?
The text was updated successfully, but these errors were encountered: