Message-Id: <199708260639.IAA10150@en1.engelschall.com>
Subject: [FWD] mod_javascript proposal
To: new-httpd@apache.org (Apache Developer ML)
Date: Tue, 26 Aug 1997 08:39:24 +0200
From: rse@engelschall.com (Ralf S. Engelschall)
Organization: Engelschall, Germany.
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org


Currently seen in the news.

Nice idea I think, but writing a complete JavaScript implementation in Perl is
harder as he expects, I think. On the other side, most of JavaScripts object
model and event handlers can be ignored for server-side. Hmmmm...  perhaps one
of us (Doug?) wants to jump on this track and write something like this.

-- forwarded message --
Date: Mon, 25 Aug 1997 00:01:31 -0600
From: agfoust@usa.net
Subject: mod_javascript proposal
Newsgroups: comp.lang.perl.misc,comp.lang.perl.modules,comp.infosystems.www.servers.misc
Message-ID: <872484916.4642@dejanews.com>
Organization: Deja News Posting Service

I haven't followed these groups all that closely, so it's possible
that the following has already been proposed:

  Develop a server-side javascript interpreter as an Apache extension
  module. Use perl (mod_perl?) to implement the module.

Javascript on the server (embedded in the HTML pages) just makes
sense. Javascript has essentially "won" on the (web browser) client
side as the most widely used HTML-embedded scripting language. Not
that it's better than perl (perl folks will most likely continue to
use perl for server side scripting); most folks coming from the
HTML front end of things will just happen to know javascript, but
probably not perl. It just makes sense to leverage javascript
knowledge by extending the language to the server. General
database access and connectivity are *BIG* items in server-side
scripting (not merely dbm and msql access), for example. Any
server-side scripting language would have to provide high-level
database connectivity features (and HTTP state management via
cookies, etc). Netscape and Microsoft know this and they are
pursuing this aggressively in the Livewire and Active Server
Page products.

Perl seems like a good choice for the implementation of an
Apache module to drive server-side javascript (or ECMAscript,
or whatever...). Some obvious reasons are: RAD, the existence
of Perl5 modules such as DBI for database connectivity, and the
excellent support and value given by the apache and perl
communities. Perl code seems inherently easier to bug-fix,
enhance, and extend over time as well. (Also, Javascript 1.2
just added perl regular expressions, so that should be fairly
easy to implement *in* perl itself!)

Anyway, I personally do not have the time or expertise to
embark on a project to implement server-side javascript for
apache. But I think it's a good idea to seed (if this hasn't
already been proposed). I believe a standards and perl-based
server-side javascript module would be a "killer application"
for the Apache and Perl platforms and communities. I look
forward to hearing any discussion, good or bad, related to
the general idea presented in this message.


[Adam Foust] * agfoust@usa.net *

-------------------==== Posted via Deja News ====-----------------------
      http://www.dejanews.com/     Search, Read, Post to Usenet
-- end of forwarded message --

                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com