My C WSGI implementation is relatively decoupled from the transport code (AJP). It's conceivable that replacing the transport layer with something else is entirely possible. Like say... a full HTTP 1.1 server. I guess there could be two directions to take that:
http-wsgi
I suppose one could take an embeddable HTTP server (or write one from scratch, if so inclined) and glue the WSGI code into the request handling pipeline. Personally, it's not a project that interests me much. Leave web server writing to the web server experts, I say. However, suppose one wrote it as an extension module for one of the popular web servers...
mod_wsgi
How about an extension module for say, Apache HTTPD or lighttpd? The problem I see with this is that, functionally, it would just be equivalent to mod_python. (After all, you're just embedding Python into the web server and patching into its request processing.) I think the only difference would be that the WSGI-adapter code (the layer that sits just above Python) would be written in C. Additionally, you inherit some of the more interesting problems of mod_python... namely conforming Python's process/threading model to that of the web server's. In all likelihood, you would be running multi-process, not multi-threaded. I guess if you were clever, you could run the Python interpreter in only a single process, similar to how CGI works in modern versions of Apache HTTPD.
But then, if you do that, all it buys you is automatic process management versus using an external server model like AJP/SCGI. So why bother with yet another mod_somethingsomething?
Anyway, ajp-wsgi will remain ajp-wsgi for the foreseeable future. (If I'm sufficiently bored and curious, I may try creating an scgi-wsgi someday.) Though http-wsgi does pique my interest somewhat... I just have to find a suitably feature-laden embeddable C web server.
