Running: Three years ago, we could run from back code. Today, not as easy. You learn to live w/in the confines of the current stuff and survive. If you get paid for your time, you are ok. If you get accused of causing the problem, and it is not your problem, you are now not okay. Therein lies the hitch.
So to avoid "guild by association" you keep the business from putting you "at risk".
Dave
Cees Hek wrote:
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 CeesImplementing 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 powerfulThis 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 doesbest, 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
-- Dave Van Abel Colorado, USA http://vanabel.com http://perlsources.com 303-249-3855 Yahoo Instant Messenger = dave_vanabel
