Wirt is correct.

Boy, is he correct.

An example.  An old BASIC/3000 (yes, written for the "classic" HP 3000)
program of about 2,800 lines (give or take a hundred) had to be
"modernized" and given a web interface.  Well, it is modern and it has a
GUI (browser) interface.  At last count it contained over 22,000 lines of
SPLash!, ran native mode on a 937, and has a transaction response time (on
the same LAN segment) of about 3 seconds per screen when used with
Navigator 3.0 or IE 4.0.  More telling are the following statistics:

   Time to complete one transaction using an HP 2934 connected via 19.2
   serial connection to a classic Micro GX with 2 Mb RAM and running the
   BASIC/3000 version of the program:

         43 seconds (average)

   Time to complete one transaction using Netscape 3.0 on a Pentium 200
   connected to the same LAN segment as the MPE/iX 937 system, utilizing
   the freeware NCSA server and native mode SPLash! code:

         54 seconds (average)

   CPU milliseconds per transaction (average)

         311 ms (average) on Micro GX running BASIC/3000 program
         562 ms (average of all processes involved - NCSA server,
                form input/output translator, and application server)
                on MPE/iX 937 system

Wow, what progress!

Chaulk up the average 9 second longer transaction completion time and
average 251 ms additional CPU cost to the cost of having the pretty GUI
interface.

Seriously, there is a serious cost to "stateless" transaction processing.
As others have mentioned, keep as much of the information about the
transaction on the server as possible.  As I mentioned in my earlier post,
if you are doing searches, keep the list of the qualified records handy so
you don't have to perform the searches multiple times.  Two significant
portions of the application server code are the sections which:

   1) revalidate the user, session, and transaction information with EACH
      request
   2) figure out (based upon the cookies, form data, and server-side
      transaction state information) just what needs to be done for this
      request.

... but if you must, you must, right?

John

At 1/7/99 01:14 PM , [log in to unmask] wrote:
>John Korb eloquently writes:

<snip all the stuff I wrote>

>A lot of people think that web-based internet transactions are difficult to
>program up, but as John explains here, they don't need to be.
>
>
>
>
>:-).
>
>
>
>If it isn't obvious, I'm kidding folks!
>
>When a process requires someone of the caliber of John Korb to go through all
>of this rig-a-ma-roll, you can tell that there's a fundamental design failure
>in there somewhere. I consider what John has accomplished to be at once both
>extraordinarily elegant and an enormous bother -- and one that won't be
>repeated by very many people.
>
>It's important for everyone to remember how easy this used to be. In the old
>days -- and John is a genuine "old-timer" -- you wrote a few lines of
>BASIC/FORTRAN/COBOL code that interacted with a terminal and the other with a
>few IMAGE intrinsics. Ten lines of simple code would get you a high-quality
>transaction processor in no time flat.
>
>What the heck is driving this phenomenon that someone like John would go to
>all of this trouble? A small part of it may be the mere technical challenge of
>it all. Doing this kind of thing is little like climbing Mt. Everest several
>times before breakfast. It's just fun.
>
>But the more profound reason is undoubtedly the fact that browsers are free.
>And colorful. And simple to use.
>
>But it's also important to remember that the complexity that John describes is
>not intrinsic to the internet itself. All of John's efforts are the result of
>the way that browser-based transactions were originally defined. A terminal
>works just as well across continental distances as does a web browser when
>connected by telnet. Telnet is just a longer wire.
>
>Far more importantly however, a terminal interface allows you to write simple
>code again. Otherwise, there is no difference between code written 25 years
>and the code that you would write nowadays. There is no such thing as a
>stateless transaction with a terminal interface. You're connected, you're
>always connected, and life is simple again.
>
>All that really needs to be done now is for someone to write a free terminal
>emulator that would be as colorful and attractive as a standard web browser.
>That would change things.
>
>Wirt Atmar
>
>
>


--------------------------------------------------------------
John Korb                            email: [log in to unmask]
Innovative Software Solutions, Inc.

The thoughts, comments, and opinions expressed herein are mine
and do not reflect those of my employer(s), or anyone else.