-----BEGIN PGP SIGNED MESSAGE----- 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
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCQEo+MJAKAU3mjcsRAsDiAJ4wf+1QraH66fUNE5xcTIY/5ZehNwCcDmAg zROBWDuQbE/9gKP/sp3tcbw= =0pTH -----END PGP SIGNATURE-----
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
