On 6/19/10 10:31 AM, Victor Subervi wrote: > Hi; > I've caught a lot of flack (imagine that) about using CGI. I understand > there are several other options, to wit: mod_python, fastcgi and wcgi. I've > messed around with mod_python without luck. What are your suggestions?
Its a slightly complicated question. First of all, it is not absolutely *wrong* to use CGI. Its just simply decades out of date, slow, and has certain problems. Primarily, that one must start Python for each and every request. That adds up: that adds up a LOT over time. The "solution" to all of these are various methods to run Python once, and keep it running and loaded, and simply call into it (i.e., execute some function you've defined) for those requests that need to be dynamic. mod_python accomplishes this by embedding Python into Apache directly. After you set it all up, there's various ways you can access it. The simplest is the publisher handler. With it, you can 'call' a Python function by linking to, say, /myform.py/view -- it'll call the 'view' function in 'myform.py'. With it, check out http://www.modpython.org/live/current/doc-html/tutorial.html "without luck" is a worthless statement to make, so I can't comment on it. But with mod_python, you wouldn't just be running it and then running your existing code as-is. The interface between the web server and your code is different in it, so you'll have to reorganize some stuff. FastCGI is a different kind of approach to the problem; it launches Python alongside Apache, and that Python stays alive forever. It just redirects requests to said process when they come in. I know very little about this model, but believe its meant to sort of mimic a CGI environment so you can sort of migrate to it easier, but I'm not entirely sure. So I can't comment on this directly, but http://docs.python.org/howto/webservers.html seems interesting (Though it speaks of ALL of these options, so is a good read anyways) Then there's mod_wsgi; this is like mod_python, but approaches the problem differently, with a bit more formal structure with an eye for interoperability. It implements the Web Server Gateway Interface specification, and lets you easily load up "wsgi apps" and "wsgi frameworks" which are a very, very nifty way to write modern web applications. But the thing is: a WSGI web application looks and is shaped nothing like a CGI application. They're awesome. Btu different. Writing a WSGI app from scratch without a framework is possible, but it seems like a terribly painful thing to go about doing. Instead, most people who are writing modern Python web applications, use some sort of framework. Django is one of the most popular. I like it. But I prefer pylons-- its a little more low level, and that suits me. There's also TurboGears, webpy, and on and on and on. The cool thing about WSGI applications is that they are "stacks"; there's a lot of "middleware" that can sit between the server and your end-application. You can add features and functionality and capabilities to your app just by adding another piece of middleware. For example, do you want to store state about what a user is doing? The things in their shopping cart, for example? A really, really elegant way is to use a "session" middleware -- Beaker for instance. It creates a unique session key, and sets it on the user's cookies. In your web application now, you can associate any kind of data you'd like with that key. And you can even remember stuff about that user if they return to your app later. Now, you could do that all by hand-- but its painful, and doing it right is not trivial. My suggestion? I can't really give you one. You're in the middle of a project. Doing it "right" from this point is basically a rewrite -- though it may not take as long as you suspect, if you use something like Django which is -very- easy. So maybe my suggestion is for now, to figure out what's wrong with mod_python for you. It works just fine. But then when this project is over, sit down and load up Django (or another of the options: look around, find one that tickles you), and spend a few days re-doing this project in that. Not for real, but for practice, to figure out how you'd do it in a proper framework. See how you like it. See how it works. -- Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/ P.S. An added plus to the WSGI app's: they'll encourage (nay, force) you to write better code. Including some encapsulation and classes and such. Which is not to say that procedural programming is /wrong/, but, for a lot of things, mixing in at least a little bit of OOP (even if you do not buy the OOP koolaid) just for organizational purposes is utter win. -- http://mail.python.org/mailman/listinfo/python-list