Closed pwtail closed 1 year ago
Out of scope for Daphne.
This is sabotage!!11
@pwtail don't use such aggressive language. You won't make many internet friends like that.
Daphne has a clear scope - it's an ASGI server. Adding WSGI support would be a lot of coding and maintenance, for little gain, since there are great WSGI servers out there.
Sorry, I was trying to make a joke)
However, I think, django sees running a single ASGI server as a sound option. As opposed to running both WSGI and ASGI and routing between them.
As I understand, when run under ASGI, a view taking a WSGIRequest, will be auto-adapted, and an ASGIRequest will be passed to it, thus breaking its code. Am I missing something?
As I understand, when run under ASGI, a view taking a WSGIRequest, will be auto-adapted, and an ASGIRequest will be passed to it, thus breaking its code.
"breaking its code" would depend on that code assuming it's passed a WSGIRequest
rather than an HttpRequest
(the base class). The latter is all that Django promises. I'm not sure there are many noticeable differences in WSGIRequest
anyway? Have you got an example of a crash?
Thank you @adamchainz for your questions, I've been able to figure that out. django has all the logic in place for this, it just doesn't "export" the API. It is relatively easy to make this functionality public as a some kind of ASGI-to-WSGI adapter, just nobody seems to be interested in that.
In other words, django contains the code equivalent to this package for example https://github.com/etianen/aiohttp-wsgi. It just keeps it private
I know that twisted can run WSGI apps - it has WSGIResource for this. Does daphne care about it, or the best we can get is the thing provided by twisted?