" Well. Actually, "problems". As I see it, there are three major issues facing frameworks on shared hosting.
First off, the new wave of popular frameworks all make a clean break from a traditional CGI-style model where the application is simply loaded and executed fresh on each and every request; this is a necessary change (reloading a framework like Rails or Django on every request would result in horrific performance), but one that causes headaches for web hosts. Second, the deployment options are so varied as to be bewildering; even when there's some sort of standard gateway protocol — as with WSGI in Python — there's still plenty of room for disagreement on how to actually *deploy* an application. To run with the WSGI example (and pick on Python a bit just to show I'm not engaging in any favoritism here): I can write an *application*that speaks WSGI fairly easily, and WSGI applications are for the most part interchangeable. But on the *server* side, it's not so clear: should the server learn to speak WSGI directly (à la mod_wsgi)? Should there be an intermediary to bridge the gap, like flup? If so, what protocol should the server and the intermediary use (flup can speak FastCGI, SCGI and AJP, for example)? Third, the new wave of frameworks are bringing languages like Ruby and Python onto shared hosting for the first time, and with that comes the problem of library support; there's a whole new world of standard modules hosts need to be aware of and be ready to support if they want to get serious about these frameworks, because asking the typical shared-hosting customer to go out and compile database adapters or image-manipulation libraries (if your AUP even allows that) simply won't work." http://www.b-list.org/weblog/2008/jan/10/hosts/ -- Dorai Thodla (http://www.thodla.com) US: 650-206-2688 India: 98408 89258
_______________________________________________ BangPypers mailing list [email protected] http://mail.python.org/mailman/listinfo/bangpypers
