|
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 software? *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" :-) ] Cheers, -g -- Greg Stein, http://www.lyra.org/
|