NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Some justification (Score:2)
However now AxKit2 is built I find it much easier to hack on than mod_perl, and not just because I know the internals. Adding a new config directive is just a matter of adding:to your plugin, which is just so sweet compared to mod_perl2 config directives. Similarly hooks are easier to write.
Profiling comes via "perl -d:Profile axkit" and running your app.
The test suite (Apache::Test) launches and stops the server almost instantaneously.
These little things make a big difference to me. Obviously people's mileage varies on that, and there is a big gap in stuff currently available for mod_perl (auth plugins being a huge example) that just aren't there for AxKit2.
The other thing is right now hacking on scalable IMAP webmail, just wouldn't work as well in multiple processes. I can cache the connection, the folders, and the mailbox contents all in a single hash. That's pretty sweet IMHO. [ However then you get into the other side of the scalability problem - migrating that to multiple web servers just wouldn't work - ah well ]
Reply to This
Re: (Score:1)
Adding config stuff was pretty bad in mod_perl 1. It's supposedly easy in mod_perl 2, but I've never wanted to add a config directive so it's not something I pay attention to. I really don't use any of the Perl config stuff in mod_perl at all. It just doesn't appeal to me.
Profiling, quick restarts -- well, they work for me in mod_perl. (This reminds me of working at a place that used IBM WebSphere, where restarting the dev tools to pick up a code change took 10 minutes! What a pig that thing was.)
You
Re: (Score:2)
Another option I'm