[Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

[Andrew Godwin]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20160104/b88fd503/attachment.html>