On Apr 05, [EMAIL PROTECTED] hacked the bitstream to say...
Soulhuntre> Hiya!
Soulhuntre> 1) It is VERY easy to have arcane errors in mod_perl code, and that code is
Soulhuntre> not as easily debugged as one could hope. While it seems that we can be
very
Soulhuntre> careful with our own code and avoid much of this - there are numerous
issues
Soulhuntre> about CPAN modules, that means much of the advantage of perl is called into
Soulhuntre> question.
OTOH, it seems (from my lurking on this list & occasional posts) that there are
many gurus who are kind enough to help out when you have a problem. i would choose
carefully which CPAN modules you rely on of course.
Soulhuntre>
Soulhuntre> 2) It seems that the stability of Apache is adversely effected - with the
Soulhuntre> most common reccomendations being that the apache config should be tailored
Soulhuntre> to restart the children every x requests to prevent memory creeping crud.
Soulhuntre>
Soulhuntre> 3) There are LOTS of posts about segfaults with bad code - this is scary :)
Soulhuntre> It seems like the perl core has a way to go to be ready for this?
i agree with your sentiments. not sure why segfaults are not avoidable... the apache
process model deals with this far better than iis to be sure though.
Soulhuntre>
Soulhuntre> 4) There does not seem to be a compatible win32/linux modperl/embedding
Soulhuntre> toolkit. I can use modperl/apache/::ASP under linux, but the same setup
does
Soulhuntre> not seem stable under win32 - and the activestate ASP perlex stuff does not
Soulhuntre> seem completely compatible.
we are using Apache::ASP with swigged c++ -> perl objects, and running
the same code under IIS w/ASP and ActivePerlScript. this lets you drop
writing hard-to-code&debug COM crap. check out http://www.swig.org.
jr
--
------------------------------------------------------------------------
Joel W. Reed http://ruby.ddiworld.com/jreed
---------------I have a 33.6Kbps modem and 1.5bps fingers---------------
