Re: Slashdot | Help Test mod_perl 2 Release Candidates

David Wheeler wrote: On Dec 27, 2004, at 9:09 PM, Stas Bekman wrote: You mean Apache::TestMB. Yeah, that ole thing. :-) I know someone who's name is David who can easily write a patch for this. That bastard is too lazy to work on it. ;-) Where is the bucket with cold water? wait, it's full of sno

Re: Slashdot | Help Test mod_perl 2 Release Candidates

Joe Schaefer wrote: Stas Bekman <[EMAIL PROTECTED]> writes: [...] I'm not against from hiding mp2 from index. I just don't understand how does it make the mp2.0 release any better? "Hey, modperl 2.0 is available, but you can't get it from CPAN using the familiar tools. Hiding it entirely isn

Re: Slashdot | Help Test mod_perl 2 Release Candidates

Stas Bekman <[EMAIL PROTECTED]> writes: [...] > I'm not against from hiding mp2 from index. I just don't > understand how does it make the mp2.0 release any better? > >"Hey, modperl 2.0 is available, but you can't get it > from CPAN using the familiar tools. Hiding it entirely isn't wh

Re: Slashdot | Help Test mod_perl 2 Release Candidates

On Dec 27, 2004, at 9:09 PM, Stas Bekman wrote: You mean Apache::TestMB. Yeah, that ole thing. :-) I know someone who's name is David who can easily write a patch for this. David, it should really be: ModPerl::MB and Apache::TestMB should use it. Of course ModPerl::MB doesn't exist yet. That b

Re: Slashdot | Help Test mod_perl 2 Release Candidates

Stas Bekman wrote: David Wheeler wrote: On Dec 27, 2004, at 7:36 AM, Geoffrey Young wrote: the only kink here would be third-party CPAN modules for only mp2 - those are _required_ to use ModPerl::MM::WriteMakefile (which knows to install into Apache2/ if that's where mp2 was installed) instead of

Re: Slashdot | Help Test mod_perl 2 Release Candidates

David Wheeler wrote: On Dec 27, 2004, at 7:36 AM, Geoffrey Young wrote: the only kink here would be third-party CPAN modules for only mp2 - those are _required_ to use ModPerl::MM::WriteMakefile (which knows to install into Apache2/ if that's where mp2 was installed) instead of ExtUtils::MakeMaker:

Re: Slashdot | Help Test mod_perl 2 Release Candidates

Joe Schaefer wrote: Stas Bekman <[EMAIL PROTECTED]> writes: Joe Schaefer wrote: My only gripe with the mp2 release candidates is that I would have liked to see a few production mp2 releases on CPAN before its mp1 indexing starts to disappear. Sure, you can ask Andreas to not index mp2 and any othe

Re: Slashdot | Help Test mod_perl 2 Release Candidates

On Dec 27, 2004, at 7:36 AM, Geoffrey Young wrote: the only kink here would be third-party CPAN modules for only mp2 - those are _required_ to use ModPerl::MM::WriteMakefile (which knows to install into Apache2/ if that's where mp2 was installed) instead of ExtUtils::MakeMaker::WriteMakefile. wh

Re: Slashdot | Help Test mod_perl 2 Release Candidates

Stas Bekman <[EMAIL PROTECTED]> writes: > Joe Schaefer wrote: >> My only gripe with the mp2 >> release candidates is that I would have liked to see a few production >> mp2 releases on CPAN before its mp1 indexing starts to disappear. > > Sure, you can ask Andreas to not index mp2 and any other 3r

Re: Slashdot | Help Test mod_perl 2 Release Candidates

Joe Schaefer wrote: My only gripe with the mp2 release candidates is that I would have liked to see a few production mp2 releases on CPAN before its mp1 indexing starts to disappear. Sure, you can ask Andreas to not index mp2 and any other 3rd party modules. But why making mp2 users suffer? I s

Re: Slashdot | Help Test mod_perl 2 Release Candidates

Geoffrey Young wrote: Perrin Harkins wrote: however, it's not as simple as renaming everything Apache2::*. why? it just doesn't scale well. for example, there are _already_ compat issues between mod_perl for Apache 2.1/2.2 and Apache2.0, so right away we would need Apache2::* for modules that us

Re: Slashdot | Help Test mod_perl 2 Release Candidates

Geoffrey Young <[EMAIL PROTECTED]> writes: > Perrin Harkins wrote: >>>however, it's not as simple as renaming everything Apache2::*. why? it >>>just doesn't scale well. for example, there are _already_ compat issues >>>between mod_perl for Apache 2.1/2.2 and Apache2.0, so right away we would >>

CPAN versioning (was Re: Slashdot | Help Test mod_perl 2 Release Candidates)

changing topics... > I was tossing around the idea of a new "api version" global. something like > > our $API_VERSION = 2.2; > > and then > > $class->VERSION(2.2); blarg, that was supposed to be $class->API_VERSION(2.2) but hopefully everyone understood that :) > > then CPAN (and r

Re: Slashdot | Help Test mod_perl 2 Release Candidates

Perrin Harkins wrote: >>however, it's not as simple as renaming everything Apache2::*. why? it >>just doesn't scale well. for example, there are _already_ compat issues >>between mod_perl for Apache 2.1/2.2 and Apache2.0, so right away we would >>need Apache2::* for modules that use the Apache

Re: Slashdot | Help Test mod_perl 2 Release Candidates

> however, it's not as simple as renaming everything Apache2::*. why? it > just doesn't scale well. for example, there are _already_ compat issues > between mod_perl for Apache 2.1/2.2 and Apache2.0, so right away we would > need Apache2::* for modules that use the Apache 2.0 API and Apache2.2:

Re: Slashdot | Help Test mod_perl 2 Release Candidates

> The real significant issue to address, IMO, has to do with CPAN's > indexing of the Apache:: modules common to both mp1 and mp2 core > distros, because those packages set the underlying apache[12] > architecture. That's what I'm saying -- don't fix it. Tell people they need to keep two perl in

Re: Slashdot | Help Test mod_perl 2 Release Candidates

"Perrin Harkins" <[EMAIL PROTECTED]> writes: [...] > I'm not wild about the "use Apache2" solution either, but I just don't use > it. Wouldn't it be easier Easier than what? Right now mp2 is supposed to autodetect a prior mp1 install and adjust accordingly. I don't know how parallel installa

Re: Slashdot | Help Test mod_perl 2 Release Candidates

> 1) expecting people to not have modperl1 for a significant time >following the modperl2 release, like everyone would "upgrade >tomorrow" thus trivializing the overlap issue. I don't see how there's more of an overlap issue with mod_perl than any other module. What do I do when I want to

Re: Slashdot | Help Test mod_perl 2 Release Candidates

Geoffrey Young wrote: I don't think we expect CPAN to grok Apache2, just the local filesystem and @INC. but you're right, the entire perldoc/CPAN/@INC thing is a real issue. don't forget that we supply mp2doc which works around this issue. what I think really needs to happen is that there should b

Re: Slashdot | Help Test mod_perl 2 Release Candidates

> I *want* modperl to succeed. I *want* modperl2 to succeed. good :) > I believe > Stas has made two significant errors in this process, however: > > 1) expecting people to not have modperl1 for a significant time >following the modperl2 release, like everyone would "upgrade >tomorrow

Re: Slashdot | Help Test mod_perl 2 Release Candidates

> "Geoffrey" == Geoffrey Young <[EMAIL PROTECTED]> writes: Geoffrey> I can't say how disappointed I am in this post, and your Geoffrey> behavior in general here. the fact is that this is a Geoffrey> complex issue, for developers and users alike, but all you Geoffrey> have done to help is thro

Re: Is there a "PerlPreForkHandler"?

> Will it take the same configuration files as the Tinc VPN, for > encryption purposes? I don't know about that, but that's why I decided to use Apache as the back end. Apache can provide encryption with https, authentication with BasicAuth and/or client certificates and all sorts of other securit

Re: Slashdot | Help Test mod_perl 2 Release Candidates

Randal L. Schwartz wrote: >>"Stas" == Stas Bekman <[EMAIL PROTECTED]> writes: > > > Stas> My submission to /.org made it to the Apache section: > Stas> > Stas> It's about asking to help testing the mp2-RCs. > > Oh goo

Re: Apache::DBI and PerlChildExitHandler

Hi everyone, Well, here's an update. VERY preliminary tests show that the PostgreSQL message in question is not caused by the child exiting. I have a 1 MacClients prefork Apache with MaxRequestsPerChild of 5 and I have a 'warn' statement on the PerlChildExitHandler to alert me when the child exits