In a little thread at http://www.livejournal.com/users/zestyping/101939.html, effbot thinks about creating another framework ("ElementWeb, anyone?"). I thought about that a little -- what would a blank-sheet-of-paper ElementWeb look like? -- but then decided that it's simply not possible.
I mean, here are the requirements for how to run applications:
1) Has to be easy to install and configure
2) Has to be installable on hosted services (where you can only upload stuff, not run separate processes)
3) Has to be high-performance.
SCGI fails 2); FastCGI fails 2), and may fail 1); standard CGI meets 1) and 2) but fails 3); mod_python can fail 1); running an HTTP server and using proxying fails 2). There's no good solution.
You simply can't have 2 and 3 simultaneously. mod_php is a model, but I don't think mod_python looks like mod_php to hosting providers -- it looks more like mod_perl (which, AFAIK, is not available on commodity hosts). OTOH, it might be reasonable to offer a couple options, including CGI (with a performance penalty tied to application complexity) and some other options like SCGI, FastCGI, HTTP, etc. Each is a compromise of sorts, but if it's easy and reliable to move around that would be okay.
In some ways easy HTTP serving makes 2 less important, because cheap hosts are in some ways an area for people to experiment, and an HTTP server makes it easy to experiment on your own computer. It still keeps someone from creating a phpBB-like program for Python and having people throw it up on any little site, but that's not low-hanging fruit at this point.
I've been thinking about putting together more server/client glue in WSGIKit. Right now invocation looks like:
server.py --server=twisted --webkit-dir=path/to/app
I'd like to support more servers and also more frameworks. One server would be "cgi-script", which wouldn't be a server so much as a CGI script builder (where the CGI script would just be the right #! line, some sys.path manipulation, some configuration setup, and the WSGI cgiserver invocation). One can imagine the same thing using one of those all-in-one CGI script builders (mxCGI or something?) that packages everything up into a zip file that can be uploaded to another host.
There's nothing magic about the server.py script, of course, except that it doesn't try to be magically pluggable or anything, just hard coding the glue necessary for existing code. I think this less impressive direction is more achievable at this point, and gives a good new-user experience. I'm actually thinking that, given a few simple standards (common configuration, this server invocation script) the proliferation of frameworks isn't so bad as long as we continue to refactor and consolidate the easy parts.
-- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ Web-SIG mailing list [email protected] Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
