> Since no asynchronous methods are available for WSGI applications, the
> httpclient and auth modules are both not available for WSGI applications.
The reason for the omission of the httpclient because of the inability of a WSGI application to set up and retrieve resources without blocking the whole process is clear enough, but I fail to see how the authentication module should suffer from this as well.
A brief glance at the code shows that the auth module is omitted because certain classes in the lib (OAuth, OpenID, etc) use the httpclient, specifically the class httpclient.AsyncHTTPClient.
Ah, so actually it is just the httpclient that causes all this. It shouldn't be too hard to come up with a version of that lib that uses some local authentication method though.
explain to me how it's possible to run any significant WSGI app inside this container. wouldn't any long-running request monopolize the whole server?
i don't have a lot of exposure to other WSGI apps besides my own, but I always use synchronous, blocking development techniques when building them, including blocking database calls.
That's correct. This is why most WSGI people (such as Graham Dumpleton, author of mod_wsgi) are opposed to adding any sort of async stuff to the WSGI spec as well.
> Since no asynchronous methods are available for WSGI applications, the
> httpclient and auth modules are both not available for WSGI applications.
The reason for the omission of the httpclient because of the inability of a WSGI application to set up and retrieve resources without blocking the whole process is clear enough, but I fail to see how the authentication module should suffer from this as well.