In article <[log in to unmask]> [log in to unmask] (Mike Belshe) writes:
 <snip>
>FYI- It may seem trivial that I make this point.  To many of us it is
>obvious.  However, I've spoken to plenty of people who have seen the WWW
>interface to the 3000 have said things like, "Finally a GUI for the
>HP3000!  I can't wait to tell my boss about this!"  To some degree WWW can
>be used as a GUI to an HP3000.  However, I want to make it clear that there
>are plenty of situations out there where WWW is not the proper interface.
 
Tell them why,  Mike :-).
 
 
Because WWW is stateless, the server remembers nothing from transaction to
transaction (or cares).  I think you said that already.
 
This problem is partially solved using WWW NCSA 1.3 authentication methods,
i.e., the Web client must send USER identifier for each request or for each
Web form POST.  On an authenticated Web transaction, the server extracts and
sets an environment variable of the USER id during the transaction, so that
update processes have a key to hang a transaction on, so to speak.
 
But the stateless method doesn't scale for short repetative data entry or to a
lesser extent, massive data retrieval.  Why?
 
Because you must open and close all files, etc. for each transaction and
reposition your file pointers each time to do an update (the true stateless
model - however, I've seen posts who want to put active database jobs
between WWW and the databases, using message file interfaces. This might work
also, but do your calculations!  This method makes the server very complex.)
 
Depending upon the frequency of updates, stateless methods can become a
liability.  On the other hand, if you free system memory and resources after
each transaction, other processes can use the free memory to speed up their
work.
 
It is the later that generally is a good trade off and makes stateless scale
well.  The concept is that while users are looking at their data or thinking
about and/or  in the processes of filling out the Web form, machine resources
are not allocated during this user "think" period (there is NO connection).
 
In fact, Our gopher server can send about 4 database queries for the time it
takes a user simply to logon without doing anything.  For large populations of
users doing inquiry, the process of simply logging on the system will kill
your system before you have a chance to run applications.
 
You better have a fast CPU (or not to full capacity) to employ large scale
stateless applications, because the applications must switch in/out all the
time.  We have had good luck with our stateless gopher  systems mostly because
we have a fast CPU and our transactions are designed very short.
 
The real reason WWW is driven today is cost, dirt cheap.  WWW offers a
pretty nice GUI client and the server is simple.  Pull a few server tricks and
maybe emulate sessions.  There is one thing you can count on, it will change!
 
 
 
 
--------------------------------------------------------------------
Eric J. Schubert                 Administrative Information Services
Senior Data Base Analyst         University of Notre Dame, IN USA
 
Email:            [log in to unmask]
Phone:            (219) 631-7306
World Wide Web:   http://www.nd.edu/~eschuber