>>>>> "js" == john saylor <[EMAIL PROTECTED]> writes:
js> hi js> On 1/31/07, Uri Guttman <[EMAIL PROTECTED]> wrote: >> and you (or your >> colleague?) never mentioned modperl before which is a totally different >> animal. apache doesn't usually exit so it will never have the end of >> process cleanup. just another reason i think modperl is a crock. it >> isn't perl anymore. js> wtf! it sure ain't ruby. it's still perl that's executing within js> apache. it is certainly a different context than what you may be used js> to- but you could say that about windows perl too. there are too many differences between a normal perl process and perl embedded in apache via modperl. ram issues, process copies, sharing stuff you don't want to share, etc. i am no modperl expert as i stay away from it. sure it has some benefits if you want to get at the insides of each request but as a computing platform it leaves too much to be desired. it can't be scaled off the box, you have to worry about other modules conflicting, you can't run your own event loop or async ops inside modperl, etc. i could be wrong but i prefer to keep apache as simple and clean as possible and use perl behind it in stem (or fastcgi, speedycgi, etc.). then you have total control over your perl process and no worries about strange things that shouldn't ever matter but do with apache/modperl. IMNSHO apache is a web server and not an application platform. merging those two is a major mistake. but of course many do and many are successful. i think it is the wrong way to do complex web apps. uri -- Uri Guttman ------ [EMAIL PROTECTED] -------- http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
