Re: [mod_python] supporting modular mod_python extensions vs."folding" mod_psp

[Greg Stein <gs...@apache.org>]

[ moving to python-dev@httpd.apache.org ; this goes well beyond what users
  are interested in... this is about policy and development, so it belonds
  on the dev list. ]

On Mon, Jun 09, 2003 at 07:31:43PM -0400, Rimon Barr wrote:
>...
> However, for reasons stated in previous emails and others stated below,
> I think that it would be even better to not include any library, and
> simply make it simple to extend mod_python with application frameworks
> or languages, by standardizing the Apache Python infrastructure.

Hunh? How the heck does that help users?

The Apache HTTP Server comes with a crapload of modules built right into it.
In fact, for Apache 2.0, we added mod_dav, mod_ssl, and mod_auth_ldap. Each
of those were separate at one point, but are now part of the standard
distribution. Why? Because it helped the users to have them "right out of
the box."

Sure, maybe mod_psp isn't the *best* thing (but then maybe it is), but it is
*something*. And that counts for a whole helluva lot.

It was also small enough and self-contained enough that it could be added in
without overwhelming the rather smallish development group on mod_python.
Code can't just be dumped at the ASF. After arrival, it must have people
able and willing to care for it. That generally precludes large code
deposits, and favors smaller bits. Bigger if the developers tag along with
it, of course.

>...
> >If you don't want to bring yourself into the argument, then make some
> >technical claims against it.  Instead of being the maurder who doesn't
> >want mod_python to be defiled.  You still haven't explained why:
> >
> >a) Including PSP disadvantages other solutions from a *technical*
> >   perspective.
> 
> - PSP will inevitably become bigger than mod_python and mod_python may
> start to look like the PHP project did a few years ago before the focus
> on Zend and PEAR finally emerged.

Maybe. Maybe not. All supposition, and it can be rectified if/when it ever
happens. This *is* open source, so it is easy to see stuff like that as it
occurs.

> - mod_python may start developing
> special "fast" hooks to the PSP engine, that will not be properly
> exposed and tested against other frameworks.

This is open source. How can you hide hooks? And if you want them for your
own framework, but they weren't fully exposed for some reason, then just
submit a patch for it. There is no reason or excuse to *not* participate in
the development, and then whine about it when it doesn't go your way.

> - Release deadlines and bug
> fixes will be end up being oriented around mod_psp changes, rather than
> around fundamental changes to the framework making the versioning of the
> framework more complex, and thereby also integration of other frameworks
> that are not as closely bound to it as mod_psp. ... etc.

You're mistaken. Development will occur around whatever interests people.
Yes, Sterling will probably focus only on the mod_psp portions, with only a
little bit of effort towards the other portions. Vice-versa for Grisha.

And they are allowed to do that. I would expect it of them. And I would
*not* expect others to try and tell them they should concentrate more of
their time on X instead of Y. Nobody has that right.

If you don't like the amount of effort expended towards the core of
mod_python, then you are more than welcome to assist. Seriously. mod_python
is not Grisha's code. It is the ASF's code, and the ASF is all about
*community*. If you want to participate in the community, and you want to
assist in the development, then you have that right. The standard ASF policy
is that if you appear to understand the mechanics of how the community
operates, and your patches are high quality, and you have the effort and
will to contribute, then you should receive commit access so that you can
directly assist in the maintenance and care of the codebase. If people trust
in your vision and how you approach the code, the community, and the
long-term care of the codebase, then you'd also be invited to participate as
part of the PMC, which is responsible for the codebase. Further on, there is
also ASF membership.

>...
> >It doesn't at all take advantage of the mod_python api in anyway than
> >any other module does.  PSP is a pure python module, with the parser
> >written in C (with flex.)
> 
> That's quite interesting. So, by your own admission, you don't really
> gain any technical benefit from integration? Ok, then what's the good
> reason to integrate, technical or otherwise?

For the USERS. Hello?! Can't forget them.

> Is it just because you can,
> being a member of the Apache Foundation and all?

Neither Sterling nor Grisha are ASF Members. They are committers, and Grisha
is part of the HTTPD PMC. There are, however, other ASF Members present on
the dev list (such as myself and Justin) who help in the responsibility of
taking care of the codebase. Not so much with the direct coding, but with
looking out for the community that should be developed around the code [for
the long-term health of that code].

> If it's merely to
> attract users through bundling, then that's an abuse, especially since
> there are so many other frameworks out there, that are far more mature
> than mod_psp.

Bunk. Go interview 100 users, and I bet they'll disagree.

Call it "abuse" if you will, but also recognize that that pattern of
thinking implies that mod_python is some public utility. Something that
everybody has a right to. Sorry to say, but that isn't the case. What is
really going on is caring for the users, and how it is possible to make
their lives simpler. We haven't precluded any options from them, but we have
made a good number of their lives simpler.

>...
> Why not sideline this entire issue and be inclusive by creating a nice
> standard extension mechanism, a repository of mod_python compatible
> modules, a prominent placement on the Apache website, etc.? A modular

Many people talk about doing stuff like this, but it is all talk. Point me
at a Python equivalent to CPAN. Oh, gee, it doesn't exist. And you know how
long that has been the case? Since at least 1997, that I recall. I bet
people were talking about it even before then.

If you want a standard extension mechanism, and a repository of modules, and
whatnot, then *please* develop it. I will give a hearty +1 to incorporating
that into the mod_python codebase/environment, and getting it integrated
into the ASF infrastructure.

But supply the code, rather than ask for it.

>...
> I know that the AF is trying to move away from language specific
> extensions, but it would be nice also to have a website for mod_python
> that looked like Jakarta, or mod_tcl, or mod_perl.

As I've said before, my favorite approach is to fold mod_tcl and mod_perl
into the HTTP Project, as other modules for the server. The per-language
balkanization doesn't help.

httpd.apache.org should make it easier to find mod_python. I've made minor
changes there, but I think a lot more could be done. It would also make
things a lot better if more material moved to httpd.apache.org. Then, you'd
start seeing Google and other indices point at the right places.

> It would help a lot
> to attract users, if that is your interest.

Possibly, but the Board did not want a Python PMC. We recommended to the
HTTPD PMC to pick up the project, and they thought that was a fine idea.
If you feel strongly about it, then send a message to board@apache.org to
reopen the subject.

>...

Cheers,
-g

-- 
gstein@apache.org ... ASF Chairman ... http://www.apache.org/