Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
From: rubys@us.ibm.com
To: tomcat-dev@jakarta.apache.org
Message-ID: <85256870.005D0F4E.00@d54mta04.raleigh.ibm.com>
Date: Mon, 24 Jan 2000 11:53:38 -0500
Subject: Re: Jsp scripting elements revisited
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline


Craig McClanahan  wrote:

> > So my initial questions are:
> >
> > 1) Is my interpretation of the page directive above correct?
>
> I believe so, and the same would apply to:
>
>    <%@ page language="perl" %>
>
> in the non-XML version of the syntax.

Sigh.  Even in my attempt to "start with a clean slate", my irrational
biases towards what I find to be the cleaner and more consistent tag-lib
syntax continue to show through.  I apologize.

To answer your question: absolutely.

> >
> > 2) Anybody have any suggestions on the shape and form of the interfaces
> > that Jasper should provide in order to enable third parties to "plug
in"
> > language support?
> >
>
> I haven't thought a lot about this before, but it seems that you've got
at
> least three high level strategies to consider:
>
> - Continue to have Jasper generate servlet source code
>   written in Java, translating <% %> scriptlets written in
>   other languages to their Java equivalents.  (Probably not
>   possible in the general case).

In general, not practical for most languages.  For NetRexx, it could be
done with difficulty.  For other languages which run on the JVM (like
Mozilla's Rhino), it is considerably more difficult because there isn't an
intermediate step where Java source code is produced.

Finally, in most cases, the Java implementation of a language (e.g., JACL,
JPython, and NetRexx) are "differently abled" (to borrow a politically
correct euphemism) than their considerably more mainstream counterparts.
To give a concrete example: the increasingly popular Zope application
server will only run on Python, and not on JPython.  This means that there
is no intersection at the moment between the Zope world and the Java world.
(Note: this is on my personal list of things to fix.)

> - Continue to have Jasper generate servlet source code
>   in Java, but encapsulate scriptlet content into functions
>   in their native language (Perl in your example), and then
>   embed a Perl interpreter in your Java deployment.  (Dealing
>   with side effects like variable declarations would be
>   pretty interesting).

That pretty well sums up my thoughts on the subject.

> - Have Jasper generate a complete servlet equivalent in the
>   other language, and execute it on top of a library that provides
>   hooks back in to the server engine.

Technically possible in some cases, but in general less interesting (at
least to me).  Looses access to JSP value add such as the JSP objects and
tag extensions.  Trying to add this back in rapidly degenerates to the
previous strategy.

Note: this is what I've done with PHP to date as it already has a well
defined means of dealing with headers, cookies, static HTML, and the like.
This brings PHP more fully into the Java world, but not fully into JSPs.
The next step is to extract the programming language out of this engine (to
be technically accurate: Zend plus the PHP extension libraries) and plug it
into BSF and therefore Jasper.

> Which high level approach you take would seem to dramatically affect how
to
> modularize interfaces into Jasper.  What approach have you been taking in
your
> explorations so far?  (It would be quite useful to see that code, even if
it
> isn't proposed as a "revolution" per se).

OK, OK, I will plan to check my code and a brief description in shortly.  A
few caveats: this code is a hack.  It is only a hack.  Under no
circumstances should this code be integrated as is.  You have been warned.

> On issues like this, the real question is "what, if anything, does the
JSP 1.1
> spec mean in this regard?"  There may be no defined answer for 1.1, but
the
> issues raised might be dealt with in future spec versions.  It would
probably
> be most appropriate to address such interpretation questions to Eduardo
> Pelegri-Llopart, the JavaSoft guy who is managing the JSP spec's
evolution.  I
> think he monitors TOMCAT-DEV (although probably not as often as
> JSP-INTEREST@JAVA.SUN.COM).

I took the opportunity to travel to Sun's offices in Cupertino on Friday
and discusses this with Eduardo personally.  Overall, I would say that he
is supportive of the explorations, recognizes that there is more work to be
spec necessary to adequate support this, and believes that some if not all
of this could be addressed in the next revision of the spec.

My intentions are to help drive the 1.2 specification in these areas,
primarily by providing an instance proof based on the current Tomcat and
Jasper code base.

- Sam Ruby