Web devel with python. Whats the best route?

[Alex Martelli]

"Chris Watson" <chris at voodooland.net> wrote in message
news:mailman.978910629.6814.python-list at python.org...
>
> I'm about to start converting the small fool proof (ha ha) admin
> system I have been working from console based to web based. What is the
> easiest way to go about integrating python into apache so I can start
> web'izing this app? mod_python, mod_snake, PyApache?

CGI.  Really.  Your admin system doesn't look like the kind of thing that
will be continuously getting multiple hits a second, making CGI overhead
a problem.  If that is the case, CGI is easiest.  *Do the simplest thing
that can possibly work*!

FastCGI appears to be a close second, with potentially better performance,
but lacking at least one CGI advantage -- the fact that each transaction
is run quite separately, well-isolated from the others, so you'll never
have any worries about resource-leaks &c... your OS will ensure proper
cleanup after each hit is processed, and you'll live happily ever after.

I suspect that you'll be using FreeBSD (to be true to your sig:-) and
so process startup costs are limited (they'd be heavier on Win32 -- dunno
about how FreeBSD compares to Linux or other Unix variants, but I suspect
it's at least as good, right?-) AND your OS is solid and will ensure
fully reliable cleanup in each case.  Capitalize on your advantages -- go
CGI, and avoid most difficulties.

"Session continuity" will have to be provided via cookies, but that's
not really all that hard -- the amount of state you need to save and
restore between hits is most likely limited anyway (making it acceptable
for cookie-residence), or else you can always use appropriate shelve
files (presumably relying on gdbm, whihc is OK) and just cookie the
shelve-access keys (that might impact scalability IF you were close to
the hit-per-second mark, but, are you _really_ worried about such loads?).


Everybody & their cousin will presumably be suggesting very-high-tech,
be-the-first-on-your block kinds of whiz-bang solutions, which ARE quite
all right when needed, but may not be an optimal match for most of the
low- to moderate-hits web-enabled solutions one _typically_ meets (and,
judging from the brief description of your application's purpose that
you supply, your case might be such a 'typical' one...?) -- so, I just
thought I'd put in a reminder that simpler, "more rudimental" approaches
are still perfectly viable, and their very simplicity may recommend them
over the more advanced ones in many cases.  Then again, maybe I'm simply
being a dinosaur on this specific theme!-)


Alex