POSIX has lot of methods, i did not found a more HTTP-compliant way to deal with it. If you have ideas feel free to expose them, i would be really happy to simplify the specs.
Regarding 9P, SpockFS is a fork of the 9spock project (unfortunately my company still did not released the sources, albeit the github repository is opened), and personally i think 9p is the currently best protocol available for sharing filesystems. Unfortunately the linux client is a bit weak as it does not manage disconnections/reconnections (once you lose the connection with the server you have to remount it)
lol :) but as already said there is no standard for POSIX access via HTTP. (WebDAV is not a competitor here, it is only the cause that pushed the development of spockfs)
Seeing it from the perspective of a network filesystem (WebDAV by itself is a lot more, albeit afaik has never been used seriously as an authoring tool) it is a bit over-engineered, but the real problem (expecially when dealing with CardDAV and CalDAV) is the clients/servers inter-operation, as it looks like no-one is able to respect the RFCs (check the amount of hacks the radicale project or davvy needed to make OSX clients happy, or the differences between lightning, korganizer and so on). So the reason is that my patience ended :)
at this point i have no idea of what an ssl vpn is :). The two kind of them i am aware of are openvpn-like (a custom service running on a tcp/udp port, but not on http) or the ones that are more "proxies" to internal networks. They do not allow to interconnect peers or to use services like bonjour or any other broadcast/multicast technology as they are at an higher layer. Am i missing something ?
Lot of networks have only access to http/https services, in addition to this you get (for free) all of the authentication mechanisms supported by webservers (like kerberos, radius, ldap and so on ...)
Ruby support in uWSGI is really solid, and it is more used than you can think of (As an example the biggest italian rubyonrails site run over it, and you will find a bunch of interesting blog posts about it combined with ruby). The main issue here is that we never pushed it in the community like we did with python and perl. Frankly i do no know why, maybe it has been a terrible error (taking in account that whoever tried it with ruby has been really excited)
uWSGI works with PyPY (Obviously with lot of limitations on the features). http://projects.unbit.it/uwsgi/wiki/PyPy
The problem is that for the vast majority of the webapps there is (still) no advantage. I only wanted to focus on that as i have invested days on (really complex for me) pypy sources, and i do not want people to ignore it ;)
If net/http (or whatever http wrapper in whatever language) gives you enough batteries for a web application i am really happy for you.
Sadly me (and a lot of other people) need a lot more.
That is why the uWSGI project exists. Things like logging, clustering, statistics, multi protocol support, alarms, time events, request routing and blah blah are added to your app for free (and the funny thing is that you can tune lot of internals without rebuilding your app).
Obviously if not having windows support is a too much high price for you the discussion ends here :)
The uWSGI project solved that "issue" (really, i have difficults calling it an issue, but i can understand the point of passenger guys) with the "uWSGI Emperor" more than one year ago in a pretty elegant (and system-friendly) way. You may want to look at it.
please do not use the suid binary approach, it is something really avoidable in various way. Check the --touch-reload option of uWSGI, you can create an empty file (writable by the user making commits/push) and use it to signal reloading.
Take it as an "infrastructure"/"swiss army knife" for hosting and deployment. Most of its features are still topic of research in autoscaling,management, tuning and so on... Most of the users do not need that features, but others (like the Emperor) can be useful for everyone. Regarding the additional layer, is something required, as your code/framework need a way to communicate with the webserver and being healthy. Nginx's mod_wsgi is an old non official module, very funny, but it works in a very different way embedding python itself in the nginx core.
in both gunicorn and php you have to choose the number of workers/processes. Most of the time (unless you use php-fastcgi) the number of php processes is choosen by the sysadmin as it maps 1:1 with apache processes. The same is true for mod_wsgi. There is always some form of configuration independently by the load. One of the reasons for some users blaming at apache+mod_wsgi is because they maintain the default (bloated) apache configuration like php users/sysadmin tend to do.
No, uWSGI has nothing to do with performance. Its strength is in the features and operational modes. Each application is diferent from the others and (could) requires specific tuning.
This is the spirit of the project, that is at the opposite of solutions like gunicorn. There is no "best choice", it depends on how you approach to system administration/development. Saying uWSGI is better than gunicorn (or the opposite) is like comparing bananas with oranges.
Regarding the benchmark, it is a bit outdated and the apache+mod_wsgi analysys/configuration is totally wrong (i am one of the uWSGI authors, but mod_wsgi is great, and seeing it blasted wrongly in that url is a bit disappointing)
By the way, do not choose your application server looking only at performance.really.
uWSGI supports HTTP and FastCGI too, natively. Using the uwsgi protocol (that has nothing to do with WSGI standard) is only a way to increase performance and add a bunch of features. uWSGI and gunicorn are very different projects, with very, very different targets. Trying to make a fair comparison is impossibile.
Regarding 9P, SpockFS is a fork of the 9spock project (unfortunately my company still did not released the sources, albeit the github repository is opened), and personally i think 9p is the currently best protocol available for sharing filesystems. Unfortunately the linux client is a bit weak as it does not manage disconnections/reconnections (once you lose the connection with the server you have to remount it)