On Mon, Jan 4, 2016 at 6:22 PM, Robert Collins <robe...@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
_______________________________________________ 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