Python/Apache stuff (was: Re: [XML-SIG] speed question re DOM parsing)
Sun, 25 Jun 2000 16:20:43 -0700
On Sun, Jun 25, 2000 at 09:40:59AM -0600, Uche Ogbuji wrote:
> Greg Stein:
> > When could I get to it? eek. I *will*, but dunno when. It is amazing just
> > how much stuff can fall on a person's plate despite having no job :-). I've
> > got some layered I/O in Apache, mod_dav integration, a new httplib, imputil
> > issues, these qp_xml upgrades, ViewCVS stuff, edna releases, free threading
> > changes, Python/Apache integration, and coding for Subversion. Fuggin
> > frightening.
> Ooh! Ooh! Can you tell us more about the Python/Apache integration item?
> We've been discussing distributing a 4Suite kit bundled with PyApache, but
> that package is quite complex and I'm not sure how strongly maintained. Are
> you talking about improvements to PyApache? Another approach entirely
> (PyApache still has much more overhead than, say mod_perl)? Do you have an
> approximate time-line? A project URL?
There are several Python/Apache efforts (where Python is embedded into the
*) PyApache: essentially this is just a CGI accelerator. Take a standard CGI
script and it will "run faster."
*) mod_python: similar to mod_perl. Built for Apache 1.3. Despite its
version 2.4, it is still a bit rough. I've been working with the author
to improve the code. I did a code review a while back with a lot of
suggestions. It is reasonable, but not as mature as mod_perl.
*) mod_snake: obvious misnomer :-). This is a module built for Apache 2.0,
with the intent of making use of Apache 2.0's threadedness (plus a few of
A2's other internal features). The code is very good looking.
- available at SourceForge
*) mod_slimpy: my name for an Apache 2.0 module which will be even lighter
weight than mod_snake. There will be only the slimmest layer of C code to
interface Apache and Python. Most/all operational logic will be deferred
to the Python side. I've used this design to good effect in some of the
Python/COM work and its univgw package in particular.
Obviously, the latter two will compete, but oh well :-). The first two fit
their problem environment without particular complications.
When I start the mod_slimpy work, I'm also going to push on setting up
python.apache.org. Essentially, it will host (under the ASF umbrella) the
mod_slimpy work plus any other efforts that may want to operate there. I'm
going to ask the authors of the other packages whether they would like to be
hosted there, too.
Of course, python.apache.org can host any Python project. It doesn't have to
be related to the web server, or any other ASF project for that matter.
Consider all the non-web stuff that operates under xml.apache.org,
java.apache.org, and jakarta.apache.org.
Greg Stein, http://www.lyra.org/