quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: [mod_python] supporting modular mod_python extensions vs."folding" mod_psp
Date Wed, 11 Jun 2003 11:43:18 GMT
On Tue, Jun 10, 2003 at 01:23:48PM -0400, Rimon Barr wrote:
> Thanks, Mike, for a wonderful email message. It cleared some things up
> for me.
> I think I need to now clarify some past terminology... There are two
> kinds of bundling, as I see it, and that's given rise to some confusion
> in reading the various emails:
>   1. Bundling at the source code level.
>      (i.e. merging the code bases)
>   2. Bundling at the distribution level.
>      (packaging separate components together for functionality,
>      completeness, etc)
> The first form of bundling is a developer issue. I, personally, don't
> care so much about this. This is open-source. Every developer should
> work on what they want! I, personally, don't think that there are ANY
> good technical reasons for integrating mod_python and mod_psp at the
> code level.

I do... we don't have option (2) available. That leaves (1) as the only
viable option.

Even if we had (2), I still believe there is utility in the (1)-style of
bundling. As a comparison point: CPAN is great. I wish it was easier to do
stuff like that, so more projects could have a similar repository. However,
the set of modules that were (by default) installed on my RedHat box goes a
long way towards defining "easy". When I went to install SpamAssassin, I had
to get more modules from CPAN. What a pain in the butt. Here you have one of
the best code/distribution repositories around, and (as an admin) it was
still annoying to have to resort to it to get some software to simple work.

I don't want to discourage anybody from creating a repository of mod_python
modules. That would rock. But I don't think it should be viewed as a savior
in lieu of simple code bundling.

> Now, I don't know whether it is the perogative of the ASF community to
> ensure this kind of fairness.

Tough question. To some extent, "no, not our problem." But on the other
hand, a rich and vibrant mod_python (extended) community is beneficial. So
there is also a "yes" in there, too.

IOW, shades of grey with no correct answer.

> However, as an open-source developer in
> the space, I lose some stamina to continue development on my package, if
> I feel that my package is going to get run over by a bundling decision
> within the ASF that creates a defacto standard. I think that the space
> is rich with development and ideas, and it would be a mistake on the
> part of the ASF to not include all this.

There are lots of defacto standards that run roughshod over other programs.
My own mod_dav module has pretty well shut down other Apache-httpd-based DAV
servers, especially now that it is part of Apache 2.0. The Tomcat and Slide
guys have stuff, but that's cuz the Java guys have an insane need to
reimplement everything. Heck, Apache httpd is another defacto standard. I
doubt the Zeus or thttpd guys are all that happy about it :-)

So how do we, as open source developers, deal with this? Write better code.

Have you noticed that Python is getting a lot of visibility and growth,
while that isn't really the case any more for Perl? The tide is swinging,
even against something as indominatable as Perl.

> There are two possible solutions that I see, and I was glad to read
> Michael Neel's recent email message on the topic. The first solution is
> an unbundling of all packages from mod_python

Per above, I don't think this is a good idea. *Something* should be in
there, but I don't have any particular care for *what* that might be.

> and making it easy for
> users to install whatever they feel like, by creating a solid
> configuration infrastructure within mod_python. I am willing to work on
> this.

This would be great!

> The second alternative is to bundle (in the distribution sense) other
> packages with mod_python, so that they are also available by default
> everywhere mod_python is available.

Also doable.

> Perhaps this is the way to go,
> although it might create more headaches down the road as the number of
> packages for inclusion increases. What would the criteria for inclusion
> become? What were the criteria in the case of mod_psp?

Apache httpd has the exact same problem. There are periodic pushes to move
modules out of the "core" repository. But then we smack up against how to
bundle and distribute those. Along with the counter-balance of "batteries
included" which is so great for users.

> So, all this is finally up to the decision-makers within the ASF. Let me
> state what I am willing to commit to as an open-source developer doing
> this as a hobby, in my spare time... As the author and primary developer
> of Spyce, am willing to maintain Spyce within this bundled distribution
> (whatever that takes). Furthermore, I am willing to assist with the
> development of mod_python to make the bundling and configuration issues
> simpler.



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

View raw message