[mod_python] supporting modular mod_python extensions vs. "folding" mod_psp

Rimon Barr barr at cs.cornell.edu
Sun Jun 8 16:43:50 EST 2003

Hi Geert,

>As the author of one of the systems you mention above, I was worried a
>bit too when the announcement was made to add PSP to mod_python.
>However, my understanding is that the component is implemented as a
>mod_python handler so that it is completely optional. I hope that it
>remains like this: mod_python as a fast and pure Apache-Python interface
>with an optional templating system.

As you are no-doubt aware, I am also an author of one of these systems:
Spyce. :) I well-aware of how to interface with mod_python. I've built
an abstraction layer underneath Spyce that allows it to operate
efficiently with mod_python and also with FastCGI, the Xitami web
server, CGI and as a web proxy.

>The good thing about this move is that new users will have something to
>get started with. On the other hand, a web framework that does a bit
>more than the standard ASP stuff is probably much larger in scope than
>mod_python, so then it would be like adding mod_python to the framework
>instead of the other way around.

I see the benefits as well. My concern is that the automatic inclusion
of mod_psp will have two effects. First, it will become a "good enough"
standard and users will not bother to look at other possibilities, which
are quite good and creative, and certainly more mature than mod_psp at
this point. I put up a web page, for example:
so that users will be able to see all the interesting things that people
are doing, and be able to select the tools that are most appropriate for
their needs. I, for example, think that I've contributed to the
community with spyce modules, spyce lambdas and spyce active tags. If
you're interested, then have a look at:
I also recognize the value in the design of CherryPy, of WebWare, of
Draco, etc. I've learned interesting things from looking at each of
these systems, and I hope that their development continues to introduce
more useful concepts.

My second concern regarding the inclusion of mod_psp is that it will end
up being a much larger codebase than mod_python, and will influence the
focus of the project from being a platform (i.e. infrastructure) for
Python-based Apache integration to being a project like Spyce and others
that are focussed on the language issues or application frameworks.
These two goals can be kept separate, but then why merge the two

Good boundaries make for good design, because short-cuts are not
possible. You, I and all other developers (and the users of our systems)
that use the mod_python infrastructure to operate within Apache have an
interest in ensuring that mod_python remains open and focussed on that
small, but most important goal: infrastructure. As a developer that uses
mod_python, I think that the most important next steps are performance
and configuration issues, not a handler for a new Python-web language.
Are there any technical merits for merging mod_psp with mod_python?

My two cents,

On Sat, 7 Jun 2003, Geert Jansen wrote:

>> I wanted to post earlier, but I didn't find the time. I find
>> this "folding" to be a little troubling. Why not fold Zope
>> into mod_python? Why not Spyce? Why not Roadkill? Why not
>> Draco? Why not Cheetah, or WebWare?
>>   http://www.zope.org/
>>   http://spyce.sourceforge.net/
>>   http://roadkill.sourceforge.net/
>>   http://draco.boskant.nl/
>>   http://www.cheetahtemplate.org/
>>   http://webware.sourceforge.net/
>> There are many others at:
>>   http://spyce.sourceforge.net/doc-add_related.html
>> Should it simply be a pure Python handler, or should it be
>> extended with more functionality? There is a difference
>> between mod_python compatability and mod_python inclusion.
>> Should there be a modular extension and/or installation
>> mechanism or should there be a "folding" for all willing
>> projects? If mod_python picks one candidate, what will it
>> mod_python do to the other projects? Will some other projects
>> begin to fork mod_python as a result? Do we want a
>> duplication of effort of either the mod_python-type or the
>> mod_psp-type code?
>> I humbly recommend that mod_python remain pure, and serve as
>> a Python handler. It does this job very well! I think that
>> what mod_python needs is the creation and documentation of a
>> standard extension mechanism to allow for
>> psp/spyce/draco/roadkill/etc. type of extensions. They would
>> not be included with mod_python, but would involve a simple .rpm (or
>> whatever) installation. (That's where the standardization
>> helps!) This will allow projects like Spyce, which works well
>> with FastCGI, mod_python, CGI, via proxying and even with
>> other webservers (Xitami) to continue to perform efficiently
>> within Apache and also to broaden the user base with support
>> for other web platforms.
>It is already quite easy to add an extension to mod_python. Mostly it is
>just the definition of the appropriate "PythonHandler" directives. What
>would really help IMHO is a good and independent web site describing the
>current situation with the many different frameworks that lists and
>rates the different options.

More information about the Mod_python mailing list