Quoting Dave Van Abel <[EMAIL PROTECTED]>: > As to "run like hell from Mod Perl", I am the one who said it and will > defend my statement. > > *Mod Perl*: > > Mod Perl is great, and I like to use it, in correct instances. > > However, when the weakly written Perl - not using strict > everywhere, getting global values from inside of sub-routines w/o > passing to it - is subject to Mod Perl, all hell can and will break > loose.
If these perl scripts are written as badly as you say they are, then you should be running from those scripts, instead of mod_perl. You are making it sound like mod_perl is to blame, which I think is unfair. perhaps you should have a look at the Apache::PerlRun module which can be useful for running 'dirty' perl CGI scripts. See http://perl.apache.org/docs/1.0/api/Apache/PerlRun.html for more info. Now if you are talking about running apache using suexec to protect the CGI scripts from each other, then you have a different problem that mod_perl can't solve at this moment. However mod_perl2 which is looking very good at the moment, but is still not considered suitable for production will solve the suexec problem as well. From the mod_perl2 docs: http://perl.apache.org/docs/2.0/user/intro/overview.html#What_s_new_in_Apache_2_0 ------ The perchild MPM is similar to the worker MPM, but is extended with a mechanism which allows mapping of requests to virtual hosts to a process running under the user id and group configured for that host. This provides a robust replacement for the suexec mechanism. ------ HTH Cees > > Implementing Mod Perl on a single server, running two sites, both > with originally written weak Perl code, can and very likely will > wreak havic with both sites. > > One site (in SSL) processes Credit Card transactions. This original > script never used "strict" and has a large number of "included" > scripts which do not use "strict". Additionally, these same scripts > are used to connect to MySQL DB. > > Now envision this set of scripts running under Mod Perl. > > Now envision someone doing a credit card transaction, and having the > CC# field populated with your credit card number (*your Visa Card > with $50,000 limit* ). Oops, it gets stolen. > > Can this happen? Yes. It happened to my girlfriend last year while > doing an on-line purchase. > > So, if any of you want to put Mod Perl up on this server, and have > all hell break loose, _and fix all the problems for free (because > you maintain the code today and therfore it must be your problem), > please send me your name, phone number, credit card number and so > on, so you can have this gig_. > > There, I've backed up my original statement and will say it again, > "Run like hell if Mod Perl gets installed for this site". > > Dave > > Sam Tregar wrote: > > >Since this topic is on the list already, here's my response on the topic. > > > >-sam > > > >---------- Forwarded message ---------- > >Date: Thu, 23 Jan 2003 13:45:02 -0500 (EST) > >From: Sam Tregar <[EMAIL PROTECTED]> > >To: Robert <[EMAIL PROTECTED]> > >Subject: Re: HTML Template versus Template Toolkit > > > >On Thu, 23 Jan 2003, Robert wrote: > > > > > > > >>Essentially, the argument in favor of using Template Toolkit is that it > >>is much more powerful > >> > >> > > > >This is true. But with power comes great responsiblity. Are your HTML > >designers ready for this responsibility? > > > > > > > >>and provides a more convenient way to pass variables to templates. > >> > >> > > > >This is not true. HTML::Template provides the simplest API of any > >templating module in Perl. > > > > > > > >>My understanding is that Template Toolkit is 'fat' and may require the > >>use of mod_perl (or something similar) to speed things up. > >> > >> > > > >It's certainly a larger and slower system than HTML::Template. > >HTML::Template is, to my knowledge, the fastest templating system > >available for Perl. And using the (experimental and incomplete) > >HTML::Template::JIT add-on, it's even faster than PHP. > > > > > > > >>Of course, the programmer in favor of using HTML Template says I should > >>run like hell from using anything like mod_perl. > >> > >> > > > >That's odd. I use HTML::Template with mod_perl almost exclusively. The > >two are a great combination and HTML::Template includes a caching mode > >ideally suited to use with mod_perl. > > > > > > > >>As the author of HTML Template, I'd appreciate any thoughts or comments > >>you might have. > >> > >> > > > >The most important issue in choosing between templating systems is your > >evaluation of your HTML designers, not your programmers. HTML::Template > >supports a very simple template syntax which is modeled after HTML. That > >means that someone that only knows HTML can learn to create HTML::Template > >templates very quickly. Contrast this to Template Toolkit, where the > >template syntax is essentially an entirely new programming language to > >learn, and the difference is clear. > > > >Also, HTML::Template enforces the division between coding in Perl and > >design in HTML. The movement of data is entirely one-way, from Perl code > >to the template and from there to HTML in the browser. This means that > >the HTML templates can be created and maintained *entirely* separately > >from the Perl code. Using HTML::Template, a Perl coder does what he does > >best, code in Perl, and your HTML designers do what they do best, design > >in HTML. > > > >All that aside, though, I don't want to leave you with the impression that > >I think the Template Toolkit is no good. It's actually a very well > >designed system which just happens to meet different goals than the ones I > >set for HTML::Template. If you do end up using it you'll still be miles > >ahead of the poor fools using JSP! > > > >-sam > > > > > > > > > > > >------------------------------------------------------- > >This SF.NET email is sponsored by: > >SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > >http://www.vasoftware.com > >_______________________________________________ > >Html-template-users mailing list > >[EMAIL PROTECTED] > >https://lists.sourceforge.net/lists/listinfo/html-template-users > > > > > > > > > > -- > Dave Van Abel > Colorado, USA > http://vanabel.com > http://perlsources.com > 303-249-3855 > Yahoo Instant Messenger = dave_vanabel > > > ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Html-template-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/html-template-users
