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.

1 of 174 comments (clear)

  1. 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.