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.

Re:Mod_Perl vs. XML issues resolved?

[scrutty]

You can't subscript a Perl string character by character

Whats wrong with this ?

@chars = split //, $string

Admittedly the split function can't work on individual characters as it needs an IFS but substr seems to work ok for me.

What about this

$ perl -e ' map{ print $_, "\n"} split // ,"qwerty" '
q
w
e
r
t
y

Or have I misunderstood ?

Re:Not really enterprise architecture

[perrin_harkins]

Separating code into MVC layers is a good start, but the real issue is the interfaces between M and V and between V and C. The article really made it sound like these components were coupled pretty tightly.

Not true. There was a clean separation. The model objects didn't have any HTML or display code in them. The templates (views) had no control flow code, only formatting. The controller knew how to pick a view, but not what was in it.

What if eToys had survived the dot-com implosion, and bought or were bought by another company? How well would this system plug into (or be plugged into) any special-needs components of the new system? That's the real acid test of maintainability in the large.

We had well-defined and documented APIs for all of the components. The hard part in integrating with another system would have been the differences in core functionality, not the interfaces.

Maybe these standards exist for perl, and I haven't used it enough in an enterprise context to stumble across them. However, you can't help but stumble across the J2EE stuff when you work with Java. Are these standards perfect? No. Are they complete? No. But they're standards, and that's what makes pluggable components possible.

Only to the extent that you can move your J2EE app from one server to another. Every J2EE app uses the basic components (EJB, JSP, servlets, etc.) in its own way. You certainly can't just connect up your warehouse management code to someone else's shipping code without a thorough agreement on the interfaces. Expecting anything more than that is just dreaming.