> > No. Bad move. CGI via WSGI must be well documented. (With added > > advice to use other methods, certainly.) > > Have you ever actually looked properly at the startup cost of a TG > application, it is quite significant and sometimes far from being sub > second. By using CGI you would get quite dreadful performance as every > request has to load the whole framework. This loading on every request > would severely impact the performance of the machine, so much so that > an admin is likely to tell you to stop it, if it is a shared resource. > It is for this reason that one shouldn't be using CGI and why it > shouldn't be recommended. > >
It's certainly, possible things have changed with TG2, but with early TG.9/1.0, I was able to set up some simple demo Intranet/internal apps that ran fine (if a tad slow) under CGI. True, they would have have bucked under even a moderate load, but the fact that it "Just Worked" for the simple case on the user's existing server, sparked interest in and willingness to commit further resources to a TG based solution. And, frankly, the expected load (internal use only) was low enough that CGI would have been fine even for permanent installation, if really needed. (Though, at the time, TG was still very immature and was ultimately rejected for that reason.) And remember, I am not suggesting that CGI be the recommended deployment method. Any CGI docs should be plastered with the appropriate warnings, and perhaps optimization tips, but they must exist. :) > > Hmmm, are you saying mod_wsgi is non-trivial to setup just on > principal or you have some reasoning to back that up. > It more political/emotional that purely technical. Without an already invested user base, adding mod_wsgi presents a problem for both use cases I mentioned: 1) The Corp IT department (or it's consulting firm), will very much want to avoid any changes to the servers that they can be liable for. If they are not already running wsgi for other apps, adding wsgi just on a whim of a single developer, is not likely going to happen. 2) The small biz owner/employee who has also been given the "IT hat" also wants to use as much default configuration as possible. Not that he/she could not figure it out, it's just more one complication. Why bother when other, seemingly equivalent, options are already installed by default? >From my perspective, both above examples are plainly (and painfully) obvious. I am somewhat surprised to even have to argue the point. Perhaps the "impedance mismatch" here is due to the main developers of TG having the liberty of working for "enlightened" employers. But, this is certainly not the case for the bulk of the potential TG2 users. TG2 desperately needs wider community involvement, and if TG2 is have appeal to anyone outside of the "Ivory Tower" of it's "Liberated" developers, some better understanding of the non-ideal development environment is called for. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
