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)
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 :)
I'm wondering if Randall regrets writing this one because of the frequency it gets cited as a argument against new standards.
Almost every commonly used Standard was born in a world with existing standards purporting to be the ideal solution for that niche.
It's not even the sentiment that the comic represents. The comic refers to standards that try to in-the-darkness-bind-them.
Competing formats and protocols should be encouraged and should compete on merit. If people use them because they are good, _then_ they can be elevated to the status of a standard.
Bad formats only proliferate when they have another driving force behind them. "It's the standard" is one of those driving forces. Proprietary (and Cathedral) software also have the "We made this and you have to use it" problem.
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)
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 ...)
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 ?
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.
Yup! I already use it - I have templated config files so I just create a symbolic link when creating a new Django app.
I didn't have to configure Emperor mode on my new Ubuntu machine - it has a directory where configs are stored. I remember 8 or 10 months ago, you had to configure emperor mode and set the "vassals" directory, not anymore I guess.
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.
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)