[mod_python] Promoting Python as web application developmentlanguage

Greg Stein gstein at lyra.org
Wed Aug 28 01:42:41 EST 2002

On Wed, Aug 28, 2002 at 01:47:38AM -0500, vio wrote:
> * Tom Emerson <tree at basistech.com> [020828 00:45]:
> > Michael C. Neel writes:
> > Look though at http://tcl.apache.org/, which includes pointers to
> > several projects for integrating Tcl into Apache. I don't see why
> > mod_snake shouldn't be included with mod_python. Developers would be
> > coming to python.apache.org to find out how to interface to Apache
> > with Python...

Note that "Apache" is beginning to mean a lot more than just "the Apache
http server". You've now got projects such as Tomcat, Xerces, and Cocoon all
under the Apache banner. Arguably, they have nothing to do with the web
server :-)

My point is just that people won't arrive at the ASF simply for "how to
interface to Apache with Python." Minor point to be sure, but hey :-)

> I'm a total ignorant about mod_snake, but in principle, promoting two siamese
> twins accomplishing pretty much the same tricks implies a good waste of 
> developer cycles (and other less valuable resources).

Each developer has the *right to choose* what they work on. You might call
it a waste, but those developers have a bunch of other reasons for why they
may work on duplicative code. For example, the Apache Tomcat guys have got a
web server built into their code. I ask, "what the hell? use Apache httpd!"
But even though that is a valid answer, some developers want a pure Java
solution, so they build a Java-based HTTP server. Even though (*IMO*) it is
a huge waste of effort. But it's their choice.

> > > I do think a "sister sites" link area is a good idea, as well as
> > > some kind of mod_python CPAN.

More on this in a sec.

> > Indeed!
> This makes a lot of sense.
> So the 'functional' hierarchy Greg Stein is promoting for the apache site
> might look something like:
> HTTP Server > modules > sister sites 
> Looks to me much more consistent that what we have now, 
> ... while making (most) everyone happy :)

I'd like to clarify my thoughts here (I've said this elsewhere, but not to
this forum, nor in a very public forum). Currently, the ASF has projects
aligned along *language* boundaries. For a certain selection of developer
and goal, this can be quite fine. "I need a Java-based MTA."

However, it starts to fall down when a question such as "I want a Java-based
XML parser." Is that in the ASF Jakarta Project, or the ASF XML Project?
Hunh. If everything were organized along *functional* lines, then the
question could always be answered properly. "An MTA? Go to the server
project. It will be in there." "An XML Parser? Go to the XML project." Of
course, you'd then select for the language of choice. But that is a
secondary criteria after the initial project selection.

Thus, I would not advocate something along the lines of python.apache.org.
"All things Python" doesn't help users looking for functionality, and it
tends to end up as a mish-mash of unrelated (Python) projects.

As a result, I would advocate mod_python as part of the Apache HTTP Server
Project itself. You've got a web server, and (hey!) here is the Python
connector. I would even advocate that mod_perl, mod_(d)tcl, and mod_php move
to this same organization (and whack those language specific projects).
Jakarta is just too frickin' huge to axe so easily :-), but there are lines
of functionality for that project, too.

In this view, vio is correct on my suggestion: the Apache HTTP Server
Project is the parent. Sub-projects include things like mod_python. And as a
matter of course, we simply refer people to other locations for other
httpd-related software.

[ and to clarify: I'm speaking of my opinion on ASF organization, rather
  than thru any official capacity ]

Back to the CPAN-like thing. Given the above view, how does this work?
Well... consider having some kind of "indexing" or "cataloging" project.
Language neutral. Sure, you could select by language, but why would it be
limited to just Perl or just Python? Why not both and Java and Tcl and Ruby

*That* would be interesting. The trouble with such a beast, though, is
simply that it is such a hard problem to put together well. If it was easy,
it would have been done. And the ASF generally prefers to avoid the "dead
SourceForge project" syndrome. We're much more about *communities* than even
the software that is produced. The end result is that a certain bar needs to
be raised to ensure that an ASF project will succeed. That it will have a
healthy community. If there is no code and no community, then there better
be a lot of trust in the (few) developers who are proposing such a beast :-)

mod_python obviously comes with a large user base and a vibrant community.
There are certainly no issues there. Mostly, I'm speaking to the concepts of
"more Python stuff at the ASF."

[ and don't get me wrong; I'm a *huge* Python supporter; Google reports
  "about 12,900" pages for "greg stein python"  :-) ]


Greg Stein, http://www.lyra.org/

More information about the Mod_python mailing list