[Prev][Next][Index][Thread]
Re: CGI/Perl vs. Middleware
-
To: Steve Mintz <tsaltd@panix.com>
-
Subject: Re: CGI/Perl vs. Middleware
-
From: Howard Jones <hjones@vossnet.co.uk>
-
Date: Wed, 18 Sep 1996 17:25:22 +0100 (BST)
-
From www-rdb-request@www10.w3.org Wed Sep 18 12: 26:15 1996
-
In-Reply-To: <32401282.25AD@panix.com>
-
Message-ID: <Pine.BSI.3.91.960918171828.21984C-100000@serv4.vossnet.co.uk>
-
ReSent-Date: Wed, 18 Sep 1996 17:25:50 +0100 (BST)
-
ReSent-From: Howard Jones <hjones@vossnet.co.uk>
-
ReSent-Message-ID: <Pine.BSI.3.91.960918172550.21984D@serv4.vossnet.co.uk>
-
ReSent-To: www-rdb@w3.org
-
X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/www-rdb/
On Wed, 18 Sep 1996, Steve Mintz wrote:
> My opinion is that CGI/Perl is "old school" and that the future of client/server
> www functionality is clearly based on in-process middleware solutions.
And in-process solutions based on DLLs/Shared Libraries make debugging so
much more entertaining too. ;-)
The halfway house that I like (as used on AOLserver, and soon to be added
to Apache) is a scripting language built in as a server module. At least
then you can take the script out of the server and into a seperate
interpreter if you need to debug it. Depending on the scripting language
(Perl/TCL/etc.) you aren't buying into one vendor quite so much either.
Another detour from the two main paths is Bluestone Sapphire whic h
generates a CGI or (soon/now) FastCGI application binary. FastCGI gives
you most of the benefits of an API, but the OS still protects your
application from the server, and vice versa.
A (slightly) related point:
Does anyone know of an 'offline' version of MS IDBC that can process the
same templates and query files but as a command line?
--
Howard Jones HELP! MY TYPEWRITER IS BROKEN!
Voss Net Plc. - E.E.CUMMINGS
Internet: hjones@vossnet.co.uk
http://www.vossnet.co.uk/people/Howard/index.html
References: