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

[Andrew Godwin]

On Mon, Jan 4, 2016 at 6:22 PM, Robert Collins <robertc at robertcollins.net>
wrote:
>
> I think that WSGI got many things right - thats why so many things
> support it - but identifying which of its attributes is a factor for
> success, and which isn't is really hard: we're a decade on, more or
> less, and the ecosystem is a lot bigger. w.r.t. ASGI, it sounds like
> mongrel2 just in earlier days. Its a nifty way to build things, but I
> think its missing a fairly important thing: its not conceptually
> simple any more.
>

I appreciate that, though I would argue that the spec makes it seem
more complex than it actually is. You can write a ASGI application in
about 4 lines, in a way that I think is no worse than start_response and
environ in WSGI:

while True:
    _, request = layer.receive_many("http.request", block=True)
    response = {"content": "Hello World!", "status": 200}
    layer.send(request['reply_channel'], response)

There's no reason ASGI couldn't have a WSGI-like layer specified on top for
HTTP requests so it looked more like current WSGI, but with slightly nicer
request and response objects. That is, in fact, mostly what the Django
Channels code does right now.

Mongrel2's design had some other issues, ZeroMQ being top of the list
(it's just not a good queuing system), as well as being way too stateful
and complex.
I could probably go on about the differences at length, but I'll refrain :)


>  - likewise on the application side: we need a Django person engaged
> with this - I reached out for one at the start of the last initiative
> but didn't manage to hook anyone, flask folk being interested would be
> good etc.
>

Hi, I am very interested, obviously.

Django _will probably have_ websocket support by next release, and it
almost certainly will run using ASGI internally; what's up for debate is
how it gets served, either via a WSGI shim, a WSGI-NG shim or native
support in a server.

I'm a big believer in going for implementation and iteration and polish
before jumping to a PEP, which is why I didn't bring ASGI anywhere near
that process yet. Once it's done, tested, implemented and we get it running
well at scale, then I think it would be ready. Django got a big pot of
funding from Mozilla just to get this process done, and several large sites
waiting to beta test things and report back how they work in the real world.

That said, I'm not stuck in some world where Django is the only Python web
framework; I would love to see the input of others. My ideal would be for a
new spec to renew the interest in writing more "raw" web apps in Python,
rather than people turning to other languages which have ostensibly better
WebSocket etc. support.


> On the asyncio / await etc side: I leave this up to the author.
> Thunking to WSGI from awaitable's would be tedious and thread-heavy I
> suspect. Obviously it can be done. AFAIK right now there is no mass
> move to asyncio from the server frameworks around: we're not going to
> solve the problems they have today with WSGI (e.g. the server-specific
> websockets requirements) by  making standardisation be predicated on
> moving something like Django to a new server core. I recall attempts
> to move other big frameworks around years ago now, taking a long long
> time.... I think the question of 'how can we enable interop of HTTP
> applications in asyncio' is best handled by a dedicated effort
> analogous to WSGI but in that programming model.
>

I agree that tying things to asyncio is a Bad Idea; any proposal should
certainly be more friendly to it, but requiring people to write fully
asynchronous code is a sure way to lose the simplicity of WSGI. We'd have
to do an incredible amount of work to Django to make it fully asynchronous
like that, to the point where it may never happen. What would probably
happen is just serving requests one at a time using thread pools or
something.

Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20160104/51c6965f/attachment-0001.html>