Dang_Perl!

[swestrup]

It is NOT pleasant to discover, when you finally think you've worked out how to set up a web site the way you want, one little niggling detail that you need to look up, and it leads to an entire humungous internet flame war with entrenched camps that you didn't know you didn't know about, and they are fighting over which, of the two different ways of doing the thing you want to do, is superior, and you realize just how much crap you're going to have to wade through in order to make an informed decision.

Comments

[thebabynancy.livejournal.com]

Can you get around it without using PERL or is it a necessity?

[sps.livejournal.com]

?! You are one weird woman!

[thebabynancy.livejournal.com]

Because...?

[sps.livejournal.com]

Eep! Eep! Eep! My brain fell off.

Here are the things I don't understand:

• Why Sti should avoid using Perl. (I mean, you use Perl....)
• How using Perl could be unavoidable. (I mean, there's Python, there's C, there's assembler if you're desperate....)
• Why getting around it, rather than solving it, would be a good thing. (I mean, better is better, right?)

Perhaps we have a Clash of Cultures going here ;).

[thebabynancy.livejournal.com]

I was simply saying that if PERL was going to be that much of a hassle... the way my brain works... is to try and find an alternative, as well. Contingency(sp) plan, if you will. I loathe PERL personally. Python is kool... as is C... PERL is one of those necessary evils in most instances. But I always look to see if there's something else that can be done.

Yup. I'm weird. *hangs head in shame*

[sps.livejournal.com]

I think my attitude is that Perl may be disgusting, but it is going to work. And if I know Sti, his script is already doing quite a lot....

[sps.livejournal.com]

Do we get any clues as to how to join in on this flamewar?

[swestrup]

Its a war between advocates of server-embedded code, such as mod_perl, mod_php, and mod_python, and the advocates of having the server run a separate task which it communicates with via sockets using the FastCGI API. Each side takes delight in pointing out flaws that the original implementations on other side had 4 years ago, but its hard to find anything balanced that talks about current state of the art. So far it seems to me:

Embedded Code

• Greater access to server internals.
• More popular, therefore more online help/documentation.
• Server can dynamically allocate resources to embedded code as needed.
• Program bugs (ie memory leaks) can cause the need for frequent server reboots, or can even corrupt the server.
• Upgrading the code while server is running is very difficult.
• Small tasks have vanishing fixed effort to implement.

FastCGI

• Separate code makes for a faster, leaner server.
• URL dispatch is simpler (no need to decide in which of 11 server phases to intervene).
• No access to server internals
• Speed-critical code can be, for example, hand coded in assembler.
• Load balancing is (to a large degree) the problem of the task, not the server.
• Code upgrades can be handled by the task, or you can just abort an old task and the server will respawn the task when needed, using the current code.
• Some coding effort required, even for trivial tasks.

So, it looks like I'm currently leaning towards the FastCGI method since what I'm doing is not going to be trivial, I anticipate numerous code changes during the life of the site and I don't see a need for access to the guts of the server. FastCGI also scales better, but only when you start talking of millions of hits per day, and at that point there's a whole bunch of changes that would be required anyway. I am still willing to consider arguments that go the other way though.

[sps.livejournal.com]

Seems to me that you might *really* want a shm-based version of cgi....

So I dunno. I used to enjoy the cgi-style interface, very clean, as you say, but if you have simple things handled by scripting, the overhead sucks. But the whole web technology always sucks, overhead-wise, because everything is inept and assumes that strings are free, regardless of length....

[swestrup]

Maybe, but that kinda requires me to be running a Linux, and a shm-enabled one to boot. Not that that is all that bad an idea for the server machine, if we ever buy it.

[sps.livejournal.com]

Shm is normal enough, isn't it?