Deprecate aiohttp.wsgi

[asvetlov]

Currently the module is not 100% compatible with WSGI standard, it works bad with big payload but introduces 'async.reader' and 'async.writer' fields in WSGI environment dictionary.

It's not documented also.

Should we support it at all?

I suggest adding explicit deprecation and removing wsgi mentions from documentation.
After 1.5 years of deprecation period we may drop the module at all.

If somebody want to support the module -- please do it outside of aiohttp project.

[fafhrd91]

gunicorn.gaiohttp depends on wsgi

[asvetlov]

Uuups.
Sorry, I've forgot this fact.

[fafhrd91]

we can replace gaiohttp with newer implementation that support both aiohttp.wsgi and aiohttp.web
and later deprecate aiohttp.wsgi support

[asvetlov]

Agree with the plan

[xpinguin]

Hi! I'd like to put my ten kopeks in, regarding aiohttp.wsgi. Turned out useless for me, as my goal was to seamlessly attach inherently synchronous wsgi app (WsgiDav in my case) to an asyncio application, where aiohttp is used only for HTTP-based protocols.
The major drawback is that aiohttp.wsgi supports only wsgi/async - custom wsgi extension, out of pep-3333 scope. This renders conforming (i.e. non-async) wsgi apps out of the game.

The solution was to develop the class which automatically performs 2way coroutine<->function conversion, thus allowing, for instance, to wrap async StreamReader into non-async one and pass it to an app. Well, no magic in here, drawbacks are obvious:

• function->corofunc <=> loop.run_in_executor(function(...)), eg. default ThreadPool
• corofunc->function <=> run_coroutine_threadsafe(corofunc(...))

... so at least we could easily have a stall in our wsgi app, although never in the main event loop, so we could adjust the pool size, swap pools, etc. - all hypothetical, had no occasion to try that out, as our real loads are laughable :)

For those, interested in actual code, here is the gist of the class (NB. it is from non-public application in alpha-stage so the clumsy code, I've also removed some aux. stuff, eg. our approach to routing, in order to be clean, just don't expect the code below to work as-is; moreover, WSGIHttpServerProtocol has poorly fitted my preference for abstractions used, so class is more-or-less application-like (conceptually, not literaly the web.Application)):
https://gist.github.com/xpinguin/e77a4a817aa1b1590de1743fa41f6671#file-wsgiapp-py

Helpers operating at the very heart, to better understand what the heck is going on:) https://gist.github.com/xpinguin/e77a4a817aa1b1590de1743fa41f6671#file-wsgiapp_helpers-py

corofunc<->func transforms, hardly any quirks, although may be interesting:
https://gist.github.com/xpinguin/e77a4a817aa1b1590de1743fa41f6671#file-coro_func_transform-py

Long story short, I do like aiohttp-core, very neat (unfortunately, couldn't say so about routers&resources). I am pretty much interested in the full-blown WSGI support, just not in the current form. What do you guys think about all that?

[fafhrd91]

aiohttp.wsgi exists because of old version of gaiohttp, i would kill it if not that

[xpinguin]

I'm not from the webdev or mobile scene, so I could've misinterpreted the design goals behind aiohttp.wsgi, sorry then... Yet still, despite my ignorance about gunicorn and all the stuff alike, "aiohttp.wsgi" sounds just perfect for the module containing wsgi->aiohttp adaptor(s), isn't it?

[asvetlov]

@xpinguin current aiohttp.wsgi is not compatible with sync WSGI apps and almost useless.
If you want to provide and support full fledged WSGI adapter -- please do it outside of aiohttp in third-party library.

[xpinguin]

Just to clarify:

• I'm working on multi-protocol storage server, whether it'll be open-sourced or not is a question of the future unforseeable
• aiohttp is one of the key components of that server, and likely will be
• Automatic WSGI->aio/aiohttp adapter was developed, adapter tries its best to preserve IO asynchronicity (and probably could even try a bit more)
• I could made some sort of FR/PR raising the code quality to aiohttp's standards, that's a lot of effort though, so the preliminary discussion in here
• ... or I could just leave it buried in my app; not being arrogant, its just the maintenance of a separate library requires even more effort

@asvetlov got your reply while writing this comment, so I leave the clarification points, yet as I understood, the answer is "don't bother with PR, aiohttp has different design goals", correct?
No problem here, if so.
However, I'd like to note, that my reasoning stems from the fact of having wsgi module in aiohttp library itself. Library which is the first pointed to by googling "asyncio http server", googling that might be done by anyone, not only webdevs - that's actually how I've got to use aiohttp in my project (and my interest in asyncio primarily lies within the context of operational semantics, event-based concurrency is just a nice thing to have; your library gains wider audience, guess I'm not the only one...)

[asvetlov]

asyncio http server doesn't mean wsgi http server :)
The main problems are maintenance and teastability.
Personally I never used aiohttp.wsgi and none of aiohttp contributors did it AFAIK.
There is a high risk of WSGI support breakage.
Thus I think the best solution is extracting WSGI code into separate library with responsible maintainer (not me).

[xpinguin]

Personally I never used aiohttp.wsgi and none of aiohttp contributors did it AFAIK.

Ahh, ok then. That renders my suggestion irrelevant.

Thus I think the best solution is extracting WSGI code into separate library ...

Yes. So if anyone shows interest towards the idea, I'd probably do that.
Thanks anyway:)

[fafhrd91]

@xpinguin i hope you understand that running sync and async code in same thread is bad idea. real approach should be spawn new thread for wsgi process and then forward data from aiohttp into that thread, but this project already exists, https://github.com/etianen/aiohttp-wsgi

@asvetlov btw aiohttp-wsgi seems pretty active, should we mention that in documentation?