perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominique Quatravaux <>
Subject Re: mod_perl userbase care (was: nuking old mod_perls before installing unstable)
Date Tue, 22 Mar 2005 16:39:27 GMT
Hash: SHA1

(Due to my recent series of blunders on this list, I wonder if
stepping up this particular plate is wise. Oh well :-)

Stas Bekman wrote:

| From the developer's point of view, this rename is insane. You
| spend most of your time coding using the API. You don't not however
| spend most of your time installing CPAN modules.

This is not my experience at all. I spend as little time as possible
dealing with the mod_perl API because (except when I'm busy adding
bugs^Wcode to my shop's reverse-proxy) what butters my bread is doing
Web apps, not programming Apache. I got the basic Apache setup and the
debugger running for my app server, and that's the very last
Apache2-dependent stunt I intend to perform on the project I'm
currently working on (an X509 PKI FWIW), until the optimization phase
comes (if it comes at all :-). OTOH I add new CPAN modules to IDX-PKI
monthly, despite its having existed for four years already!

| I believe the so called *community* has no idea what is awaiting
| them. Hardly anybody is on that dev list.

Lumping all mod_perl users into a single "community" category obscures
the issues at hand quite a bit IMO.

Allow me to refine this concept in the context of this list into two
very distinct categories, "core community" and "peripheral community".
The "core community" is exactly the set of those people who are
directly concerned with how mod_perl precisely works:

~    * the mod_perl developers such as you;
~    * the early adopters such as me;
~    * the maintainers of the Apache:: modules;
~    * the web hosting shops who want to have a mod_perl offering;
~    * the hackers who want to do something cooler with Apache than a
~      "conventional" Web app server (exotic WebDAV database
~      front-ends, reverse-proxies, mail servers etc.)

I think all of these folks are quite able to do a quick s/use
Apache::/use Apache2::/ or something: none of the proposals so far are
rocket science, really. Actually we can (and are eager to!) deal with
whatever bright future the Apache and mod_perl teams combined will
enlighten us with, and we know there will be efforts involved. Hence
the conspicuous absence of screaming in pain on the list when talking
about turning the namespace upside-down.

OTOH the "peripheral community" is composed of "indirect" mod_perl
users: that is, people using ModPerl::Registry or any of the CPAN Web
frameworks such as embperl or Openinteract. Those may very well be
newbies, but if they are suitably shielded from Apache by the tools
they use, they most likely won't notice there *is* even a difference
between mod_perl 1 and 2 except for a few shibboleths to adjust in
httpd.conf (which they should be prepared to do anyway when switching
major versions, and will *have* to do for e.g. mod_ssl).

Most "core community" members are also part of the "peripheral
community" because of their day job. Except when dealing with mod_perl
itself full-time, as maybe you are lucky enough to do Stas?
(Absolutely no offence intended anywhere in this mail, I'm just curious.)

| At the moment the community knows that the API has been frozen
| already and moving full speed to mp2. It doesn't know about the
| changes we discuss on the dev list.

You mean here "peripheral community" I guess, because as regards the
"core" members, we know. The namespace issue has done quite a bit of
splash already, including on Slashdot where it has been described as
one of the release blockers, so nobody can act surprised.

| If mod_perl sucks it's a big problem. IMHO, the moment you've
| released that new API you will probably need to start preparing a
| "R.I.P. mod_perl" tombstone and start looking for a new job, most
| likely doing Java or PHP, which are sane enough not to embed
| version numbers in the API. It'd be a pity.

And making the Apache API (and *only* it) just as version-dependent in
Perl as it is in C causes mod_perl to suck why?

(and don't worry, nobody here is switching to one of the "other two"
anytime soon >:->)

The "core" vs. "peripheral" sociological distinction seems to map
perfectly to the API that can vs. shouldn't change in mod_perl:

~    * only the "core community" is concerned with the way e.g. one
~      changes the Apache configuration from mod_perl, and this API is
~      of course bound to change at least as often as the Apache-in-C
~      counterpart does. Besides, the "core community" is prepared to
~      deal with this neccesity (see above);
~    * on the other hand, it would ineed be nice to allow all
~      "peripheral community" users to continue using mod_perl as they
~      used to do, without wrinkles. This "customer care" concern has
~      very little adherence with the mod_perl codebase (Apache::compat
~      is (nearly) good enough as it stands for having $r->foo() behave
~      as before). Moreover, the burden is *not* solely on the
~      shoulders of mod_perl itself: obviously, all application server
~      authors (AxKit, embperl and so on) will strive to provide a
~      seamless migration path to Apache 2, masking API discrepancies
~      with conditional code in their own framework if they have to
~      (possibly, this includes wrapping $r into a delegate with an
~      object class which does *not* m/^Apache/, just to gain control
~      over its API). As regards mod_perl itself, I consider this job
~      *done* already, regardless of the outcome of  the naming
~      flamewar, since Apache::Registry scripts work perfectly under
~      ModPerl::Registry (actually better, re. END blocks). Thanks Stas
~      and all for this!

| But by working around the CPAN problem (which refuses to grow up)
| you create tons of other problems.

Actually having "use Apache2;" change your @INC is not very elegant
either, and creates its own set of problems. Having to use "mp2doc"
instead of "perldoc" is one, for starters (now *that* does discourage
the "peripheral community" types, e.g. my coworkers).

CPAN breakage is the tree hiding the forest there, the point is that
you cannot just hide the huge, moving Apache API behind a fixed
Apache:: curtain without losing all three of performance, API coverage
and principe of least astonishment in the not-so-long run. Let's deal
with that "tons of other problems" on an agressive basis: mod_perl's
Apache API should be as close as possible to it's C counterpart, up to
and including breaking upward compatibility everytime Apache does.
Glue code should be written in pure Perl, and mostly not by the
mod_perl team.

Regards, joy and peace,

- --
Dominique QUATRAVAUX                           Ingénieur senior
01 44 42 00 08                                 IDEALX

Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message