[mod_python] Killer Web Apps

Hi Dustin,

I agree. And, let me follow up on that by expounding on an earlier
suggestion that I made... I think that mod_python should focus on
building a standard extension mechanism rather than begin folding
"killer" features such as mod_psp. This will mature the entire Python
web community.

What I mean by standard extension mechanism is to define something
similar to the Linux Standard Base project, albeit much smaller in
scope. mod_python needs a configuration file/directory for extensions
with a specific location. It needs a versioning mechanism, a way to find
the Python interpretter, some scratch disk space (for caching, or
whatever a plugin needs), etc. It needs a simple extension namespace and
registry (i.e. files in some directory) to find out what other modules
are available, or perhaps an RPM (or Windows registry) naming
convention... little details that allow for automated installation and
configuration across multiple platforms and configurations. They really
are just little details, but they can make the difference to a new user
between perceiving the project as a hackish solution versus a polished
one.

This is the major advantage that PHP has - it just plugs in to Apache.
And that's why ISPs just plug it in! It would be nice if mod_python just
plugged into Apache, and then Spyce/Draco/WebWare/etc just plugged into
mod_python to form a working Python web-serving system. Ideally, I think
it should be a two RPM installation, or just two setup executables on
Windows. This this exactly the situation with Apache/PHP/Pear and it
works well.

On the API front, I think that mod_python needs to make threaded output
more efficient, and possibly support output buffering. Currently, I'm
performing hacks in Spyce for both of these, and they could be
implemented more efficiently inside mod_python (and in C) with
substantial performance gains on the output path. Other frameworks would
benefit from this as well.

In general, the concern that I have with the "folding" of mod_psp into
mod_python is two fold. First, it may integrate with mod_python via APIs
that would otherwise have been exposed and have benefitted all the
Python-based web projects. Secondly, it may become the defacto standard,
no matter how it compares with other tools for a specific task, simply
because of its tighter integration and automatic inclusion. It will be
seen as a standard, and it will stifle the creation of useful tools in
the space. PHP, for example, has recognized this problem, and has
created PEAR. Perl did the same with CPAN.

We don't need to have something as extensive, but it would be nice to
have a basic extensible Python-based web infrastructure of some kind,
and mod_python is the place to do it, since it is now part of the Apache
Foundation and therefore a central member of the Python web community.

My two cents,
Rimon.

On Sun, 8 Jun 2003, Dustin Mitchell wrote:

>Let's take a step back and look at what we're doing here.
>
>We're trying to invent the perfect solution to everyone's problems.  Now, any
>of us that have done any appreciable amount of web development know that
>there is an enormous variety in the tasks that are out there.  No single
>solution is going to hack it for every problem.  Personally, I use Zope, PHP,
>mod_python with publisher, mod_python directly, Python CGI, and occasionally
>the Python interpreter and GNU make.  Every task calls for different tools.
>
>If you want to design a killer app, take all of the "I like this feature" and
>"$PRODUCT has that" that you see here, generalize completely, and build a
>framework into which each can be plugged on an as-needed basis.
>
>What you'll end up with will be Apache with mod_python, though perhaps with a
>little bit more pluggability on mod_python's part.  Right now, that's where
>we should be focusing our attention.  What are the paradigms under which you
>wish your web server would invoke your scripts?  How can the Python-facing
>end of mod_python be structured to support that paradigm?
>
>My $0.05
>
>Dustin
>
>