Session/client side execution?

Session/client side execution?

Post by Steve Hens » Thu, 07 Sep 1995 04:00:00



I wonder if anyone can help with the following problem. For a certain
application the following are required.

A "session" of some sort. User logs in, does some things with web pages,
others are created relating to the responses to previous forms, then
when done the user logs out. Some form of client side execution would
help, so for example the range of fields and validity could be determined
locally, and perhaps organising the session this way with a single connection
instead of trying to make many single requests look like the same session
at the server end, it would also allow things like allowing prompts to appear
when fields are entered, jumping around between fields, the usual stuff that
is done in you average GUI form (or even character based form) but which can't
be done with any browser I have seen. The 'script' facility mentioned in
HTML 3.0 would appear to answer some of these concerns; does any browser
implement this in any way ?

The planned target is Windows 3.1 client and SCO unix (ODT 3.2v4.2) server.
This rules out Java (for the moment) and also things like NSAPI (the netscape
server doesn't run under SCO, and this would need to be developed outside the
US anyway). A way of achieving everything would be to use a custom Windows
3.1 application which uses a winsock to talk to a custom server application,
but this would be tricky to develop, unless something like this existed
already.

If the client side stuff is ignored (it would be nice but not essential), this
can be done with CGI, where the cgi program is a 'client' on the server
sending requests to a 'server' on the server which then would then handle
all the CGI requests and store any necessary session information and send back
appropriate replies. The client on the server knows the right session to talk
to by any standard method (client cookies, hidden fields or embedded in the
request). This is fine up to a point but it has a few problems.

The "impatient user" who clicks on other links, "reload" or even "stop". This
can be handled by recognising the server client connection has vanished and
either sending the orginal reply back to a new connection or aborting the
original request. This means the server client needs to determine quickly when
a connection has vanished, I have been using cern httpd but it buffers the
CGI output and will appear to indicate all has transferred OK when the
connection has gone, do any other httpd handle this better ? If the user hits
'stop' then little can be done as far as telling the user what has happened.

It seems like many applications are being developed that would benefit from
something that could handle these concerns cleanly. However doing this kind
of thing with CGI is messy at best and is something CGI/http was not designed
to handle in the first place (a single connection valid across a whole session
would be much better). However bending the web to something it can just about
handle (albeit under protest and barely satisfactorily) is much easier than
starting from scratch.

So thats the problem, does anyone have any solutions and/or comments ?

--
***********************************************************************

*                               *       Steve Henson.                 *
*                               *                                     *
***********************************************************************

 
 
 

Session/client side execution?

Post by Michael Co » Sat, 09 Sep 1995 04:00:00



>I wonder if anyone can help with the following problem. For a certain
>application the following are required.

>A "session" of some sort. User logs in, does some things with web pages,
>others are created relating to the responses to previous forms, then
>when done the user logs out. Some form of client side execution would

Maybe the session management in a server like spinner could help ?
It claims "Built-in support for encoding and decoding of state in URL's.
This simplifies scripts or modules which have to keep state between connections."

The operation of the GUI you want sounds a bit like the config in spinner.
http://spinner.infovav.se

Quote:

>The planned target is Windows 3.1 client and SCO unix (ODT 3.2v4.2) server.
>This rules out Java (for the moment) and also things like NSAPI (the netscape

There is now a Windows 95 version of hotjava, the java browser, and I don't think java
needs any special server.  But I take the point that Win 95 is not Win 3.1
http://java.sun.com

Michael.

 
 
 

Session/client side execution?

Post by Jon Richard » Tue, 12 Sep 1995 04:00:00


What you are suggesting is solved by the CCI standard at NCSA. (Common Client
Interface?)  I have only seen this talked about at a conference, so do not
know where it might reside on the WWW, but I'd try www.ncsa.uiuc.edu to begin.