revisiting web development in Perl...where to start? - Page 2

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

Re: revisiting web development in Perl...where to start?

Quoted text here. Click to load it

die "Tad";

Re: revisiting web development in Perl...where to start?

Quoted text here. Click to load it

I second that recommendation.

Quoted text here. Click to load it

Can you describe this "style of coding"?

Quoted text here. Click to load it

The CGI protocol (from the viewpoint of the CGI script) is basically:

* At startup, information about the header of the request plus some
  other information is in the environment.
* The body of the request (if any) can be read from stdin.
* The response (including headers) must be written to stdout.
  The end of the response is signalled by closing stdout.

At least on Unix-like systems (and this where CGI was invented) this
means that a process running a CGI script cannot serve more than one
request: There is no way it could get a new environment, and it cannot
reopen stdout. So the server must start a new process for the next

FastCGI got around this by

 * transmitting all the information from the web server to the fastcgi
   script through the socket.
 * Designing the protocol in such a way that both sides can signal "I am
   finished with this request" without closing the communication

So the FastCGI script can continue running, and the web server can just
send one request after the other to it.

Java application servers use similar techniques.


Re: revisiting web development in Perl...where to start?

Quoted text here. Click to load it

Yes. I can't say this is a global categorization, so please don't take
this too literally, but maybe as an impression and not as mutually
exclusive methods or styles.

HTML by itself is simply a markup language, it's not a programming
language. There are two ways to use HTML with programming: you can
either write the HTML and embed the programming elements in the HTML,
like PHP or JSP, or you can write the application and have it emit
HTML as output.

It's been my impression over the years that when people say 'CGI' they
don't mean using the CGI protocol in a literal sense, but writing
scripts that output HTML.

In my case, I write a lot of scripts that are heavy on the
computational side and light on the output side. For example, I just
finished a script that input two data files, one of about 37,000
records, chopped them to pieces and rearranged the data, and output
about 85 PDF files, 1 CSV file, and several HTML files. I don't know
what you would call this style of programming, but with respect to the
generation of HTML files I would call it CGI using Perl, not because
it uses the CGI protocol in any way, but because it's the way I once
wrote CGI scripts (and continue to write web applications, whether in
Perl, Python, or something else.)

I know that this isn't an accurate use of the term, but it conforms
with how the term seems to be used by the world at large.


Re: revisiting web development in Perl...where to start?

Quoted text here. Click to load it

Most people I see these days are using PHP.

That doesn't mean it's better! (I use PHP, primarily because everyone else
does.. as someone who knows their way around both, I assure you, PHP sucks)

One thing PHP does pretty good at is templating, it's a web designers
templating system, not a serious programming language.

Believe it or not, CGI is still pretty common, aside from the bloated
nature of, it's still a pretty good fit. There is a CGI::Lite(?)
module I used once or twice, it's good.

One thing I'm surprised no one has mentioned is FastCGI(?)

I've spoken to people who use mod_perl and they're now in the process
of moving toward "fastcgi". I like fastcgi because, with a little careful
design, you can make an application that can switch from CGI to FastCGI
and back again. (have to use clean code for this)

The advantage with plain CGI is, you don't consume resources for scripts
that are run maybe once a day and they're also MUCH easier to debug.

FastCGI is really good for cases that have a lot of hits, it beats the pants
off of other technologies (cough, PHP) because the process sits in memory. It's
great for loading in things like configuration data and then sharing them with
any new requests.

FastCGI is not a good fit for administrative control panels or utilities that
are seldom run.

FastCGI (indeed, any serious perl work) is generally only found with people who
know what they're doing, so if you're looking for opportunities, perl probably
isn't it. (this is very unfortunate)

You asked what people are using today, in terms of popularity, PHP wins.
(be prepared for massive irritation if you use it..)

-- Custom web programming
Perl * Java * UNIX                        User Management Solutions

Site Timeline