Oh whoops! I forgot to press the save button on the dns management page. Should go through now, certainly within the next hour.
On fastcgi - fastcgi is not a server in itself - you cannot connect to it with a web browser. Like Passenger, it's a way for a server like nginx or apache to launch and talk to processes which return webpages directly. The easiest way to run camping apps for many different users would be regular CGI. You might think this as being terribly slow - but I assure you, if ruby and it's libraries are stored on a fast SSD disk, ruby launches incredibly quickly - further, the operating system's disk cache creates an in-ram copy of popular applications and ruby libraries, allowing the more heavily used hosted camping apps to become even more responsive. CGI certainly not worth ruling out. PHP works like this - loading and recompiling each of it's source code files for each request, unless special optimisation is done - like facebook's php to c compiler. If CGI is too slow or consumes too many resources, there's also a middle ground worth exploring - Unicorn uses a forking system, which is rather cool because it launches new ruby instances very very quickly - practically instant. It wouldn't be all that difficult to make a forking server variant which forks on each request and loads up a user's application, runs it, then closes (or maybe idles out after five minutes). There are all sorts of interesting ways we could optimise existing server ideas to work very well with small infrequently used applications on different domains for different fully isolated users, rather like the ways PHP tends to be hosted which make it so practical for large numbers of users running infrequently accessed applications. Sandboxing is also something worth investigating. _______________________________________________ Camping-list mailing list [email protected] http://rubyforge.org/mailman/listinfo/camping-list
