Slashdot Mirror

← Back to Stories (view on slashdot.org)

E-commerce with mod_perl and Apache

Posted by michael on from the camel-power dept.

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.

3 of 174 comments (clear)

  1. I love Perl. by tshak · · Score: 1, Flamebait

    I love Perl - it's a great scripting language. So is PHP (as seen on my useless website). However, for powerful web applications I could do without either one. No matter how elegant the design, the word "spaghetti" comes to mind. Now, switch over to a fully compiled, OOP, event driven "paradigm" (sorry), and you've got me hooked. Whethor it be Java Servlet's with JSP, or more favorably ASP.NET with C#.

    --

    There is no longer anything that can be done with computers that is nontrivial and clearly legal. -- Paul Phillips
  2. OO Maintainable Perl.. by thesupraman · · Score: 1, Flamebait


    For all the good(ish) things about perl (a massive developer community, libraries to do ANYTHING, reasonable performance under mod_perl, and instant recognition), describing perl as:
    'Through the use of Perl's object-oriented features and some basic coding rules, you can build a set of code that is a pleasure to maintain, or at least no worse than other languages.'
    is rather laughable.
    Perl has a tacked-on-the-side OO layer that kind of works if you are careful, and I don't think anyone would argue against the well known write-only feature of perl code. Maintainable yes, equal to other languages? Less likely.

    However, I find the most interesting part of the article the switch from MySQL (popular, but has REAL trouble scaling, I know I will get flamed for that, but it is my real experience) to Oracle. I wonder what other systems were tested? If they were getting a significant speedup with a berkely-db cache of serialised objects, then they were not getting a lot of performance from their database.
    I would have been very interested in a comparison between their Oracle setup and a PostgreSQL system, given their need for local caching running a PostgreSQL cache on each machine could have been quite a win.

    Their code samples given certainly do not represent 'clean and maintainable code' to my eye. perhaps they should invest in a python book, possibly the most readable language I have yet found (but will not stop looking).

  3. Re:Mod_Perl vs. XML issues resolved? by Animats · · Score: 3, Flamebait
    Perl, interestingly, isn't very good for processing structured text files efficiently. The usual state-machine parser (get next character, get type of character, fan out on type) is inefficient in Perl, because "get next character" from input is slow. The obvious approach results in shifting the entire input string by one character for each character removed. You can't subscript a Perl string character by character. (This is a religious issue for Perl zealots.)

    As a result, Perl parsers for HTML, XML, and SGML typically have the tokenizer written in C. "expat" is the low level part of an XML parser written in C. So Perl programs that parse HTML, XML, or SGML typically have a C component.

    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.

    It's an annoying limitation of Perl.