Well, some of this is more emotional than logical, but I've been half wanting to vent about ePerl for a while. I never would have seen ePerl except I was trying to see if FilterProxy could accomodate my simple browser customizations like dropping certain ads, adding "softwrap" to PM text boxes, stipping most but not all scripting, flagging interesting bits, etc.

Okay, the first problem was that I was only looking at the source code because I couldn't get it to compile under Windows NT and the first thing I notice is lots of big claims about how incredibly portable the code is ("ePerl was written with portability in mind."). But my annoyance at that really started to climb as I kept seeing tons of C code that should have been much smaller, much more portable Perl code. In the end, I read a whole lot of C code and didn't find anything that wouldn't have been better done in Perl. There might be some in there, but I didn't find it.

Now this may not be a great reason to avoid using ePerl except that this will stop you from moving your code to a non-vanilla-Unix platform and there are plenty of alternatives to ePerl available.

At first, making their code portable was pretty easy. I just had to #ifdef out bits that didn't apply under Windows NT and fix some small bits of stupid, unportable code by replacing it with smaller, less stupid, more portable code that worked better than the original, even under Unix.

But eventually I realized that their lack of understanding of portable programming had permeated their code too deeply for me to be able to quickly patch it back into sanity and I gave up. I realized that I could probably write a tiny Perl-only replacement for ePerl faster than I could fix their C code (though I didn't plan to support whatever they were doing to support some CGI security features that I didn't even glance at since they were of no use to me).

Okay, much of the code was not as ugly as lots of code I've seen. As I said, this is an emotional rant. I hope the authors of ePerl never see it, by the way.

So what are some of the things they did wrong?

My favorite is:

    fseek(fp, 0, SEEK_END);
    nBuf = ftell(fp);
    [...]
        if ((cpBuf = (char *)malloc(sizeof(char) * nBuf+1)) == NULL) {
            ePerl_SetError("Cannot allocate %d bytes of memory", nBuf)
+;
            CU(NULL);
        }
        fseek(fp, 0, SEEK_SET);
        if (fread(cpBuf, nBuf, 1, fp) == 0) {
[download]

Then there are little things like:

            fprintf(fp, "%c", c);
[download]

Well, the whole design seemed convoluted for what looked to me to be pretty simple functionality.

It can be slow, I had to modify how it caches to get it to work properly, it was just a mess and had been changed so much, my old boss renamed it kPerl. Mason is the buzzword of the day (for good reason) and is a better choice.

Cheers,
KM

Ahh, okey... I see. I must agree, Ralf hasn't been updating it "recently". In fact, it won't compile out of the box on Perl 5.6.0, but there's a rather quick fix to that.

You mention it can be slow... Are we talking like big, big sites here, or what? I use it for some "webified" system administration only, so...

BUT if there are security issues, maybe I'm better off looking elsewhere for my perl-in-html embedding. I'll have to look closer into this... Thanks for the info!

Off the top of my head I can't recall any real security issues. In fact, I gutted the bastard and put in my own security, which was secure :) So, I don't recall if I found any.

And yes, I am talking a large site with a few million hits/day handling a few hundred thousand Db queries per hour. I think whenever I fixed what was wrong with the caching, it sped up. I wish I could remember the details, but I seem to have blocked it from my memory.
Still, try Mason or something that you could actually reuse for a larger app later on.. since using ePerl would be silly.

Cheers,
KM

Hi, I'm fighting with incorrect working of ePerl cache at the moment :( Could you send your kPerl or your ePerl cache replacement?