server-side java
Anselm Baird_Smith (abaird@www43.inria.fr)
Mon, 16 Dec 1996 14:30:24 +0100 (MET)
Date: Mon, 16 Dec 1996 14:30:24 +0100 (MET)
Message-Id: <199612161330.OAA01322@www43.inria.fr>
From: Anselm Baird_Smith <abaird@www43.inria.fr>
To: "S. Alexander Jacobson" <alex@virtual.office.com>
Subject: server-side java
In-Reply-To: <Pine.LNX.3.93.961211140636.17385A-100000@virtual.office.com>
S. Alexander Jacobson writes:
> Various people have suggested alternative environments including
> fastcgi-java as well as the javasoft jeeves servlets which I
> forgot to mention in my original mail.
>
> I guess this brings up an intersesting point. There are actually a few
> separate questions to ask?
> 1. is there already an httpd-independent or standard in-process
> server-side java environment?
> 2. since there appears to be that there is no httpd-independent or
> standard in-process server-side java environment, is there one we can
> adapt to provide this function?
> 3. if each existing model is too loyal (proprietary) to a particular httpd
> implementation or too difficult to port to all the platforms (including nt
> and macintosh os's and the netscape and iis webservers) then can we
> define a standard interface that would
> a. allow code sharing among the various server-side java developers
> around the net analogous to the cgi/perl script sharing?
> b. facilitate writin code which maps our new interface to the
> proprietary java server apis in the way that database vendors
> provide odbc drivers
>
> Is anyone interested in such a project?
The only "standard" thing, as o today, is the servlet API, that Jigsaw
will support in next release (it's done, needs a little more testing,
but should be ready by next release). Now, wether this is standard or
not is another issue, I don't know what vendor will support that API,
I know a number of free Java servers will support it though.
Anselm.
BTW: I didn't had time to look into the fastcgi stuff, Iwould really
like to have a FastCGI resource(that does fastcgi within Jigsaw, by
opposition to the cgi fastcgi gateway that was mentioned earlier)