It depends what the application uses mod_perl for. If it is simply using Apache::Registry for cache reasons, it shouldn't be hard at all.
If it is touching any of the phases which mod_perl allows you to (logging phase, cleanup phase, etc...), then
chances are you are up the creek.
Cheers,
KM | [reply] |
| [reply] |
Some people (such as me) don't think that mod_perl is the
best architecture. I think that fastcgi or speedycgi
are the better ways to handle persistent perl programs.
joe
| [reply] |
People who understand the internals enough to _know_
when an app is better one way or the other have no trouble
with converting them. People who are starting with other
people's code and trying to warp it off of the assumptions
that lay under it whilst being built likely aren't in
that class.
So merlyn's question was fair, Why do that?
And btw, even though I helped on the mod_perl project early
on and use it every day, I agree that it isn't for every project.
If persistence is your main goal and the total count of
scripts is low and you have no reason to hook into the
server itself, mod_perl is an awfully big stick to hit your
project with. =)
"Code softly and carry a big CPAN with you." (heh)
--
$you = new YOU;
honk() if $you->love(perl)
| [reply] |