Slashdot Mirror
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.
I remember my first expierance with mod_perl. I was working for a small development company. That's not the key part
:)
The key part is that I was in charge of the perl backend, and it was really lagging. Loaded mod_perl up and *bam*, we had a fast enough system. I never did a serious benchmark, but it was like 100% improvment
Thus all I can say is good job guys! This doesn't surprise me at all, and it's good to see recognition get passed around in the correct quantity for once
If you've had a bad experience with PERL, give Perl a try!
how to invest, a novice's guide
Fully compiled? Servlets? C#? Apparently you've never heard about this thing called "byte-code". It's definitely not fully compiled. Perl doesn't have to be spaghetti, either. Read the article. If you know how to use Perl 5's OO features and ensure that you (and everyone you devlop with) always use them, you can stay on top of things. Not to mention the advantage you get from using a higher-level language.
eToys had over 100 people coding plain vanilla HTML... is that a good example of how mod_perl can be used as an ecommerce app server?
mod_perl definately has it's uses, but eToys is a bad example. Remember, eToys went out of business, in part because they spent way too much money on hardware and had way too many employees doing simple jobs.
You would think a large site like eToys would make good use of templates and would reuse programming objects all over the place. This wasn't the case for eToys at all.
eToys initially felt it was too difficult to use mod_perl to create templates or reuse objects on their site. They almost never reused elements in their pages, and they had very few templates. There was hardly anything there you could call an 'application server', and most of their pages were not dynamic (outside of store item entry).
Instead, they had over 100 HTML people to write the HTML for just about every single page on their site. It wasn't a very large site either. When I say 'HTML', I don't mean 'they wrote DHTML or PHP or java or perl. They had 100 people writing plain vanilla *HTML*.
Towards the end, eToys hired a few smart folks who knew the capabilities of mod_perl. They were on their way to creating a templated dynamic site. In the middle of this new effort, they went bankrupt.
(I used to work for eToys. Posting as AC to protect me from Toby Lenk's lawyers).
It's fixed in Apache 1.3.22. You could also disable the EXPAT rule when compiling Apache.
how to invest, a novice's guide
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.
Actually, Scheme can be compiled. There are a number of implementations that just interpret it and relatively few that actually compile (Bigloo, MIT Scheme are the free ones that I can think of).
My only political goal is to see to it that no political party achieves its goals.
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.
Matt. Want XML + Apache + Stylesheets? Get AxKit.
Whats wrong with this ?
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
Or have I misunderstood ?
-- Oh Well
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.