> > Although, this may not be the best deployment method, there should be > > a well written section on how to deploy via plain CGI. (This is the > > lowest common denominator on shared production servers ) > > To be honest I'll prefer to get people away form CGI, to the point of > making it undocumented. > >
No. Bad move. CGI via WSGI must be well documented. (With added advice to use other methods, certainly.) Why? Because in several major target markets for low-volume TG use, the developer does not have an authoritative final say on deployment server configuration. Case #1 : Corporate Intranet deployment ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ No corporate IT admin will allow a department-wide, or company-wide, application to be deployed on a developer's private "homebrew" server. Never gonna happen. No way. Further, IT departments are notoriously loathe to add runtime support for the latest wiz-bang framework that some newly-hired departmental developer wants to use. But, a request to deploy a low volume app via Pyhon/CGI would likely be granted. A request for the production server's Apache to be reconfigured with mod_wsgi... less likely. Now, once the slick new application is being used and liked by other employees, a request to redeploy under mod_wsgi/mod_proxy would be far more likely to succeed. Case #2 : Small biz Intranet ~~~~~~~~~~~~~~~~~~~~~~~~~ Here, there may be no "IT department". The "developer" may in fact be a regular employee with other responsibilities. The "developer" needs a simple way to deploy an application on a "server". So he/she takes an old workstation and loads CentOS/Ubuntu Server with a GUI installer. Out of the box it's configured with Apache and CGI support. (And, ahem, PHP...) Now, how much more mucking around is required to get the application safely deployed? standalone mode: Fussing with server autorun files, and making a heartbeat monitor to restart crashed apps. mod_wsgi: Better, but still installing apache module, and non-trivial server config file editing. cgi: Just works. Perhaps with some basic .htaccess edits to use mod_rewrite for nicer URLs Again, as usage grows, better options can be explored. Case #3 : small website ~~~~~~~~~~~~~~~~~~~~~~~~~~ A neighborhood business or non-profit has a "web hosting account" at any of the commodity web hosts, and wants to add some dynamic content to their website. Again, without an "IT Department" upgrading to even a cheap "virtual private server" just ain't going to happen. Thanks to the success of Ruby-on-Rails, FastCGI support is now fairly common. TurboGears has a chance here if the user can figure out CGI (and eventually FastCGI) deployment. > > > After that, a section on FastCGI, followed by mod_wsgi, etc. > > Did you miss http://www.turbogears.org/2.0/docs/main/Deployment.html Yes, I saw it. That is what prompted my comment. :) (BTW, it has some broken links...) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
