Chris said:
We used perl, and regretted it for the web interface.
[snip]
If by "we used Perl" you mean you used something like HTML::Template or
Template Toolkit, then I am surprised at your statement. IMO,
HTML::Template coupled with Perl, separates the logic from the
presentation about as well as anything and provides much flexibilty and
power. I much prefer this technique to PHP. It sounds like you didn't
use a templating solution.
We used a template system, I'll admit, the template system wasn't ideal, but
that was not where the problems were. The template system did keep the
logic away from presentation, but it was awful to use because it was _very_
strict about how it did it, NO perl allowed in the templates at all,
everything was either static HTML or had to come from a function outside of
template space. I perfer the jsp syntax, (and because I like perl, later
wrote a template system using JSP syntax w/out the tags, but it wasn't
available for this project.)
I'm not trying to sound bigoted because this is c.l.p.m. I'm *in*
c.l.p.m because I've *been* bigoted *by* Perl. (I hope you see the
difference). I've used a lot of so called "web solutions" out there --
ASP, PHP, JSP, CF, Ruby, even .NET etc. -- and I keep coming back to
Perl. It rocks them all AFAIC.
I quite like perl too actually. Even though I'd been burnt by mod_perl (this
was 4+ years ago) I still might try and find some way to use it because I
really do like it.
I'm very surprised at this statement as well; mod_perl is "the bomb" --
it's rock solid. mod_perl on an Apache server can do ANYTHING. I'm not
trying to cast a shadow on you or the resources you had available to
you, but I can't help but express surprise at some of your statements,
because entirely the opposite has been true for me.
It was 4 years ago. (During the tail of the dot-com era) mod_perl *was* nice
for the simple things, but when I used it for stuff like storing database
connections (and yes, I used Apache:
BI) I had terrible memory leaks. Tried
different variations of them but couldn't weed them out. Removed DBI and the
leaks went away.
Now I *know* others didn't have this problem, in fact, most people probably
didn't. So, maybe it had something to do with the other modules I was using,
maybe it had to do with the order they were loaded in, could have been
a buggy database driver, I really don't know. (was using DB2 if that matters)
We also employed DBM as part of the session handeling, again.. problem area
periodic segfaults on the web server. The purely-perl stuff was absolutely
wonderful, though.
Give me Perl/mod_perl, Apache, MySQL, and HTML::Template and I'll put
together a multi-tiered, multi-server, load-balanced web solution that
would better anything (probably faster) put together by Java, PHP or
JSP. My opinion, but I'll bet many here would second it.
I know they would. (well, less the MySQL bit, mysql is not for "real"
database work)
I'll remind you at this point that I was _very_ happy with perl for the
"middle tier" stuff, just not mod_perl. You would not believe the amount of
flack I got for using perl on this project (I was the project mgr.) But, one
person (me) was able to write 90% of the code on this. In Java we would have
had to use several java developers. So, yes, I can definately appreciate
perl.
The most pain-free solution I have come up with for "sessions" in a
load-balancing situation is to take this data to the back-end or add
this as a separate tier as well. The extra time and resources taken for
lookups is worth the pain it removes esp. if your back-end solution is
tuned properly.
Yes, if the cost of having extra servers do sessions is justified, it'd be
the best idea. A lot of it boiled down to "how much are sessions worth?" In
our case, they weren't worth that much. Have to be careful not to make a
central point of failure though, simply using NFS or MySQL would have been
by far the easiest.. until that server goes down..
One thing I'd really like to see (and maybe this is done already, haven't
looked) is mod_webapp or some such working with a perl back-end much the way
servlet/tomcat does. I hate the java language but do like some of it's
ideas.
If there were were something akin to "out of process" servlets written in
perl I'd seriously consider it. In fact, if I had 4 months of spare time,
I'd code one myself becase it'd be a fun project.
(Hmm.. maybe perl
compiled to support multiplicity would be a requirement, with support for
each 'webapp' getting it's own instance of perl?)
Hmm.. and if this 'perlette' were taken down in an orderly fashion it could
have the option of mirroring it's sessions some place so that when clients
are directed to other servlets, the sessions are restored.
Anyhow, we were talking about large scale perl apps. I'd hold my ground on
keeping perl away from apache. Both perl and apache are complex software
packages and binding perl to apache would be a lot like embedding perl into
an OS's kernel - (kernel == good), (perl == good), (perl + kernel == very bad)
If PHP keeps on it's current track, I'd say the same for it. It needs to
stay fairly simple or it'll create problems with apache.
Jamie
