|
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: http://spyce.sourceforge.net/doc-add_related.html 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: http://spyce.sourceforge.net/doc-mod.html http://spyce.sourceforge.net/doc-lang_lambda.html http://spyce.sourceforge.net/doc-tag.html 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 projects? 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, Rimon. On Sat, 7 Jun 2003, Geert Jansen wrote: >Ramon, > >> 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. > >Cheers, >Geert
|