I wonder if a sensible first tack onto this might be: Supporting an ASGI/asyncio request-response cycle in 2.2 might be a perfectly achievable goal with or without funding. Users wouldn't be able to use the ORM, or much of the default middleware, but for some gateway-type services I can still see it being useful.
A proof of concept there might help validate (or otherwise) both the motivation (run some actually tests against a service that makes outgoing HTTP calls and then returns a response - what sort of throughput can we achieve there vs. the threaded case?) and the feasibility (what aspects that we haven't considered do we bump into along the way to implementation?). Perhaps we could work on the basis of (1) pulling together a proof of concept there, and then (2) attempting to get that into the 2.2 alpha freeze, without being blocked on getting together the rest of the plan & funding for the more substantial parts such as the ORM work? That wouldn't necessarily preclude also getting asnycio ORM work into 2.2, or achieving funding early on, but would at least give us something valuable to start working towards immediately? -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/b994f620-cfb9-4e4c-aac7-c601be809b5b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
