If Not CGI...

[Stephen Hansen]

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.