RE: Making sure...

>JSPs scare me.  Seems there could be a security risk, but I won't know
until
>I play more.

Why? JSPs actually get compiled into a servlet at load time, so they
function
exactly the same as a servlet. What is does is allow you to separate the
static HTML from the dynamic code. Much like Net.Data. In eRPG I store the
static HTML in files and then read it into the CGI program. Really the same
result except with JSP there are design tools emerging (WebSphere Studio
and Ultradev to name a couple) that allow you to design your JSP pages
WYSIWYG
with placeholders for the Java (JSP tags).

>Servlets.  LEt's just say that at this piont comparing to e-RPG to servlets
>is like comparing flying a paper airplane to a 747 as far as complexity to
>do something simple like read data from a web page.   But maybe one day
that
>will change.

I think they are very similar in many regards. Getting environmental
variables
is a method call rather than a subprocedure call (assuming you encapsulated
the C APIs in a service program). You can simulate most of the request and
response methods with subprocedures if you want. Doing things with session
is nicer. They do scale better because of spawning threads for each request.
Overall, I see many more similarities than differences. One advantage is
standardization. Everyone uses the same objects and methods where as in RPG
is varies depending on how the subprocedures and service programs are set
up.
The large class libraries available from Sun and IBM provide for a lot of
functionality right out of the box.

>Now I challenge all of you to try out e-RPG.  :)

I have. In fact I did that based on your MC articles before your book was
published.

Joe

+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---