E-commerce with mod_perl and Apache

rob_99 writes: "Cool new mod_perl article at perl.com documents building a large scale ecommerce solution w/ mod_perl & apache!" Pretty cool stuff - it's kind of funny to think how ephemeral their work turned out to be.

Comments

Re:PERL - the "Write-Only" language...

[chromatic]

I've had that problem with PERL, but then I discovered its predecessor, Perl. It's a much nicer language -- it has warnings, an optional pedantic compiler mode, lexical variables, embedded comment support, a debugger, copious documentation, numerous libraries, and active user communities. Best of all, it's not limited to CGI!

If you've had a bad experience with PERL, give Perl a try!

I don't think thats what he meant

[stuce]

TrustCommerce offers a drop in .pm module as well for people writing perl front ends to their web sites. The Raven SSL package allows apache to serve https, not make ssl connections from a perl program. The trouble with SSL in perl is not serving https+mod_perl, its in writing those easy drop in .pm modules for connecting to the eCommerce gateways. Lucky for all you eCommerce site developers, we gateway programmers get to worry about that, not you.

I don't think Adam's comment was meant to detract from the power of something like Mason and mod_perl for developing web site front ends. It was just that of all the API's we have open source libraries for (C, Perl, J2SE, J2EE, Python, PHP and ColdFusion), the Perl module was by far the hardest to develop as the existing tools lack some important features.

Re:Mod_Perl vs. XML issues resolved?

[Matts]

That C component has to go into the Apache server (and run with server privileges, with all that implies, like a potential for buffer overflow attacks) for mod_perl programs to use it.

Complete and utter BS.

What are "server privileges" ? Everything in apache runs under the nobody user (or configurable).

What potential for buffer overflow attacks? Show me one.

The component does *not* have to go into the Apache server for mod_perl programs to use it. Not even slightly. If that were the case, DBI would be unusable from mod_perl, wouldn't it? No-siree, the C component (expat) was included in Apache to support mod_dav. They modified expat slightly (and called it expat-lite), and thus we had symbol conflicts, and the wrong code being executed, and BOOM. So now Apache 1.3.22 uses the DSO expat, same as XML::Parser does, and the problems are gone.

Someone please mod me up or him down. Facts can be checked in the mod_perl and mod_perl-dev list archives.