|Pathologically Eclectic Rubbish Lister|
Re: Perl vs mod_perl and PHP in Apache+MySql setup on WinXPby etcshadow (Priest)
|on Dec 29, 2004 at 01:48 UTC||Need Help??|
Q: Why would one need Perl and mod_Perl, as it says here, to work on Apache? What extras do I get with mod_perl? Would Perl+CGi be just as good or better?
As revdiablo excellently stated, mod_perl is mostly useful as a speedup over perl CGI. On win32, however, it has some more implications, because it brings the perl interpretter (which is not multi-threaded) into apache (which is). You see, apache and mod_perl were really originally targetted on linux/unix which deals with web servers and other such things using multiple processes, rather than multiple threads. However, there is a new apache 2 and a (almost ready for production use) mod_perl 2, which are meant to work in a multi-threading (as opposed to multi-processing) environment.
With mod_perl, there's also the ability to use perl to hook into and control the apache server using perl rather than C... which apache without mod_perl won't allow you to do.
Q: How different is mod_perl form ActiveStates Perl 5.8.4 running under WinXP? Will I need to learn mod_perl? Can I just get away with the Perl version that I am currently using?
Again, revdiablo beat me to it: the standalone perl interpretter (whatever version) is not significantly different from the same version of perl interpreter compiled into apache via mod_perl. There are some differences in how you code things, though, because of the nature of how the interpretter is used, but not really because of differences in the interpretter. For example, under mod_perl, you should be much more careful in using global variables, because their values persist from one request to another (since the perl interpretter is still running from one request to another). Likewise, there are additional speedups you can gain from using mod_perl intelligently, by making use of the fact that variables persist from one request to another: for example database connections and file handles may not need to be opened and closed on every request, they can just be stored in global variables and reused.
Q: In this tutorial, it further introduces PHP here-- yet another scripting language! Can I ask why? Specifically, what is it required for that Perl and/or mod_perl canít do?
Why does php exist? Well, different people want different things out of languages. You'll see lots of different languages out there in the world that fill basically the same niche, but were developed for slightly different reasons or by different people. Why are there so many different unix shells? Why are there different programming languages at all? The short story about php in relationship to perl is this: perl is a general-purpose language which is well suited to to web work, but wasn't made specifically for it; php was specifically designed for web work, and so some would argue makes that specific task easier while frustrating its use as a general purpose language... and don't forget that many web sites do a lot of more "general purpose" programming behind the scenes. But I honestly wish to avoid a php-vs-perl argument. That is a very short, and probably wrong, one-sentance comparison.
Q- If I am going to have all the above then I don't undertand why do I still need Mason? , where does it fit into all this?
Mason is a perl library which is a useful tool for building web sites that are more maintanable. You don't need to use it (or any other templating tool), but you may find it (or one of its bretheren) useful. The idea is, basically, rather than writing a perl script that says something like:
you would write a Mason template something like (and forgive me for not knowing Mason's syntax... I use Apache::ASP (one of Mason's kin)):
That's all. It's just a tool to go from sticking HTML inside a perl script, to sticking perl inside of an HTML file. It can be useful if you want an HTML editor (and you can take that to mean either software or "wet-ware") to work on your combo html/perl... the html editor can just ignore the perl bits, or, more to the point, take them for granted.