Actually, I think it would be more appropriate to do 2.0.6 with the
Apache::* decoupling, then 2.2.0 for the APR::* decoupling.
2011/1/31 Fred Moyer <f...@redhotpenguin.com>:
> Another thing that comes to mind after rolling the 2.0.5 rc is that we
> should start shipping the Apache-* based modules separately as CPAN
> distributions when we release 2.0.6.
>
> The MY::test section in Makefile.PL will need to be overriden so that
> it skips the test suit if Apache-Test isn't present. The code to do
> that is in a couple of other Makefile.PL files, and it pretty solid at
> this point.
>
> We should be moving towards more modularity; trying to get mod_perl
> 2.0.5 out has definitely seen the coupling of the Apache::* modules to
> it as a bottleneck. I think that if we can remove the Apache::*
> modules from the distribution with 2.0.6, Gozer may be able to work
> his magic and decouple APR::* from mod_perl in 2.0.7. Wouldn't that
> be cool :)
>
> 2011/1/28 Torsten Förtsch <torsten.foert...@gmx.net>:
>> Hi all,
>>
>> a few questions that come up in my head every time when I think about
>> modperl:
>>
>> - how long do we want to support old perl versions?
>>
>> For example, modern perls do not support anything but the perlio model. Stdio
>> was officially dropped in 5.8.7 or so. If you need to change some of the
>> related code in modperl it becomes really hard to test it. Older perls do not
>> compile in a modern environment and newer perls perhaps can be built without
>> perlio but the test suite will fail for sure.
>>
>> - can we really support windows?
>>
>> Do we have any developer who builds/tests/cares about modperl on windows? If
>> yes, I withdraw the question. If not, how can we claim modperl runs on
>> windows? I have tried to build apache & modperl on windows. But my last
>> encounter with it as a developer dates back to the mid-nineties. So I failed
>> badly already on the preliminaries. That doesn't mean anything if we have
>> someone on the team who can.
>>
>> BTW, could this someone please document in a fool-proof way (for me) how to
>> build modperl on windows starting with which compilers to use? Where do I get
>> or how do I build an usable openssl, that sort of stuff. Suppose you have a
>> freshly installed Vista or Win7 virtual machine.
>>
>>
>>
>> Perhaps, a few more points to discuss. They are a bit of a TODO list what
>> could be improved in modperl:
>>
>> - big: refactor threading code
>> * implement a fixed sized interpreter pool
>> * start perl interpreters before forking off worker children (use COW at
>> least a bit)
>> * implement PerlInterpInit and PerlInterpExit phases (like ChildInit/Exit)
>> these hooks are run by the worker processes for each interpreter. Do we
>> need also per thread init/exit phases? I doubt that, but ...
>> * make -Dusemultiplicity -Uuseithreads possible
>> * improve "PerlInterpScope handler" (mainly by writing test cases)
>> * better configuration (instead of +Parent and similar):
>> <PerlNameInterpreter myappv4>
>> PerlSwitches ...
>> PerlModule ...
>> <Perl ...>
>> </Perl>
>> </PerlNameInterpreter>
>> <PerlNameInterpreter myappv5>
>> PerlSwitches ...
>> PerlModule ...
>> <Perl ...>
>> </Perl>
>> </PerlNameInterpreter>
>> <VirtualHost ...>
>> PerlUseInterpreter myapp4
>> ...
>> </VirtualHost>
>> <Location ...>
>> # perhaps we can offer different interpreters even here
>> # at least starting at HeaderParser
>> </Location>
>> * implement interpreter usage monitoring via mod_status
>>
>> - smaller but not without pitfalls: implement a proper shutdown for
>> $r->child_terminate
>>
>> - small: drop the tied-IO code and refactor/simplify the perlio stuff.
>>
>> - small: fix the leak in (reuse the brigade instead of allocating a new one
>> from the pool)
>>
>> while( my $chunk=get_some_chunk ) {
>> $r->print($chunk);
>> $r->rflush;
>> }
>>
>> - small: I believe we have a leak with a perl that is compiled with
>> "-Dusemultiplicity -Duseithreads" and code of the type
>>
>> $r->push_handlers( Perl*Handler => sub {...} );
>>
>> or in a .htaccess file
>>
>> Perl*Handler "sub {...}"
>>
>> where the actual handler is a anonymous subroutine or a closure.
>>
>> - implement a way to untie %ENV after fork() in a handler
>>
>> - there is Parse::Perl on CPAN. With a few tweaks that could be used or some
>> ideas be adopted to improve Modperl::Registry
>>
>> - better support for other MPMs
>>
>> Sometimes it itches me to tackle the big one. But then that is minimum 4-8
>> weeks full time for me. With tests and documentation even longer. Last year I
>> couldn't afford that. I doubt this year. It's quite a large chunk of my
>> yearly
>> income.
>>
>> Thoughts?
>>
>> Torsten Förtsch
>>
>> --
>> Need professional modperl support? Hire me! (http://foertsch.name)
>>
>> Like fantasy? http://kabatinte.net
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org
>> For additional commands, e-mail: dev-h...@perl.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org
For additional commands, e-mail: dev-h...@perl.apache.org
