Message-Id: <199606181810.OAA23920@breckenridge.openmarket.com>
To: fastcgi-developers@openmarket.com
Subject: Re: crummy build process for FastCGI-integrated Perl
In-Reply-To: Ray Zimmerman's message of "Tue, 18 Jun 1996 12:41:58 CDT."<v02120000adec97c08dfd@[128.84.239.231]>
Date: Tue, 18 Jun 1996 14:10:36 -0400
From: Mark Brown <mbrown@openmarket.com>
Ray Zimmerman asks:
I confess that I haven't looked at the fastcgi source code (I'm
probably not entirely qualified, to be honest) ... but I'm
wondering, Mark, if getting into the perlguts and implementing
your own filehandle type is necessary. With just a conceptual
overview of how fastcgi works, it would seem that it could be
implemented almost entirely in Perl ... is this not true? I'd be
curious to know why not?
I see two issues.
The primary issue is that functions like print and printf are pretty
darned fundamental to Perl. If FastCGI doesn't implement a filehandle
object, then FastCGI programs can't use these functions to write their
output. That makes FastCGI programs second-class citizens.
(The existing filehandle object won't do because FastCGI needs to add
protocol wrappers on the connection back to the Web server for output,
and interpret the procotcol for input.)
The secondary issue is that there's already a perfectly good protocol
module written in C. I, for one, have no interest in translating it
into Perl and then maintaining that version. If somebody else wants
to do that, no problem, but it feels like the wrong engineering
decision to me. The module facility of Perl-5 was designed to make
writing extensions in C easy. No doubt it is easy once you know what
you are doing.
--mark