> > And forking a new process under mod_perl
> > really defeats the purpose.
>
> Does it?
Well I confess I just assumed.
> I used to believe that too, but now that I've developed
> applications that make rather extensive use of the Apache API, I would
> actually love to have an environment similar to CGI but
> providing the full
> Apache API, including logging, notes/pnotes, etc.
How would it be similar to CGI then? I'm guessing you want to be able to
register a separate program to handle any part of the request phase?
> I certainly don't like the way we're all assuming mod_perl
> 2.0 is going to solve all our problems. It won't.
Well, personally, I use my own servers when I use mod_perl, so this
particular problem doesn't affect me. But I think that finding a good
ISP-friendly mod_perl solution would be good in general to help promote Perl
as a viable modern web programming language. I think that promoting perl as
a *modern* web programming language would be good for the perl community
because it would encourage more people to use modern programming practices
(strict mode, OO etc.) rather than the quick one-offs of yore that were so
popular with CGI. Not that there's anything wrong with that of course.
I know some people who run a small ISP and they would probably consider
offering a mod_perl service, if they could put a bunch of users on a box and
protect the users from each other reasonably well.
Of course, mod_perl is not the only way to promote Perl on the web, but this
is a mod_perl list :)
Michael
