in reply to Re: What is mod_perlite?
in thread What is mod_perlite?

To get the environment they're trying to build in mod_perl, all you have to do is set MaxRequestsPerChild to 1.

Except that mod_perl is still a single global environment for all Perl programs such that one customer's global changes could overwrite another customer's global changes.

If the "correct" solution to that is "why don't you just give each customer his own private server?", then mod_php still has clear superiority over mod_perl in the $4.95/month hosting market. I believe Clayton Christensen wrote authoritatively about the dangers of ignoring that.

Replies are listed 'Best First'.
Re^3: What is mod_perlite?
by perrin (Chancellor) on Jan 22, 2009 at 19:48 UTC
    Except that mod_perl is still a single global environment for all Perl programs such that one customer's global changes could overwrite another customer's global changes.

    That's true for server config changes, but not for anything you can do after server startup (i.e. without root). When you set MaxRequestsPerChild to 1, everything is gone at the end of each request.

    I don't see any need for mod_perl to compete in the hosting market when FastCGI is already ubiquitous, and has this same capability. (The Ruby hype was good for something after all!) I think these guys should have taken a closer look at FastCGI before they decided that cheap hosting was a problem.

[reply]
      I like the focus of the project, but I agree with what's been stated. I don't think they will add anything beneficial for Perl 5. My question is: do the internals of Perl 6 change significantly enough for a project like this to work? (Not having to reload the interpreter...keeping the web scripter's code at arm length so you have a clean container after the script has been run.) If Perl 6 can provide an environment where a mod_perl6lite would work just like mod_php, I think the web would shift back to Perl.
[reply]
Re^3: What is mod_perlite?
by redhotpenguin (Deacon) on Jan 26, 2009 at 17:02 UTC
    'If the "correct" solution to that is "why don't you just give each customer his own private server?", then mod_php still has clear superiority over mod_perl in the $4.95/month hosting market.'

    I see your point, but I don't think that the term superiority can be applied to solutions in the $4.95/month hosting market. I'd say that for $4.95 a month, a user would be lucky to get a functioning anything.

[reply]
      I don't think that the term superiority can be applied to solutions in the $4.95/month hosting market.

      How many of those hosting accounts support mod_php? How many support mod_perl or (to perrin's point), FastCGI with Perl support? Technical superiority is not the only kind of superiority.

[reply]
        How many support ... FastCGI with Perl support?

        What is there that makes you think more accounts would support mod_perlite? How would it be easier or safer for them to use or offer? I've read (what I believe are) all the articles on the subject, and asked questions, but still am unable to see any added functionality that mod_perlite brings (and, honestly, it's not for want of trying, I personally don't find shooting down criticising open-source projects to be an enjoyable pastime).

        Technical superiority is not the only kind of superiority.

        So what superiority does mod_perlite bring? Can't be early adopterism or ubiquity, so is it a marketing drive for mindshare? That's got to be based on something. What is that something? Ease of use, ok, fine, but where exactly is it easier to use? Fastcgi is an "apt-get install libapache2-mod-fastcgi" away on my platform, where does mod_perlite get easier than that?


        All dogma is stupid.
[reply]
[d/l]

In Section Meditations