Thought I should weigh in on this, as I got mentioned by name in it. Sorry about maybe not getting the threading right, I wasn't subscribed to the list still it sprang from the grave this morning!
So, to quote the reply I just sent to Cory in django-developers: I don't think ASGI would be a suitable replacement for WSGI in the current form; in particular, I suspect it will have a performance disadvantage, though I've not quantified yet. That said, if Django Channels does become the primary method for communication with web clients, the only thing we would want out of WSGI 2 would be something that could easily plug into ASGI - that is, something that supports WebSockets, can handle simultaneous connections with many clients in the same thread via cooperative multitasking or similar, and allows raw access to sockets. Given those things, an ASGI HTTP/WebSocket protocol server could simply be a WSGI 2 application, allowing much better code reuse. In particular, ASGI is never going to be low-level enough for people who want to do crazy things; there's no access to input and output socket streams, for starters. While I've tried to maintain some of the WSGI familiarity, the whole thing is one step higher a level of abstraction, and with that brings inflexibility and slight performance decreases that I suspect people will get mad about if it becomes WSGI 2. Now, I do think that the majority of web frameworks out there right now could be ported to ASGI in no time at all; the asgiref package I'm working on will ship with an ASGI-to-WSGI wrapper that just makes that work, as long as the WSGI application doesn't try and be too clever with output I don't want to express an opinion on if this means WSGI 2 is unnecessary since I'm pretty biased; we need _some_ sort of standard that covers WebSockets going forward, or we have the uwsgi problem where everyone invents their own API for it. My wishlist, though, is basically: - WebSocket support - Concurrent client handling support - WebSockets and HTTP mixed-mode (i.e. on the same port and URLs) - Fix the bytes/unicode issue that's all over the place in the current spec These would all work super well in making ASGI itself pluggable into WSGI 2. HTTP/2 features also need some place (like server push), and there's other things cropping up like WebRTC that we might need to eventually support. This is one of the reasons ASGI separates transport from protocol encoding; I know people will invent new crazy web stuff in the next few years, and I wanted a pattern that could extend to support most protocol types without changing the abstraction completely. Andrew
_______________________________________________ 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
