Message-Id: <199602151023.EAA08372@library.wustl.edu> Date: Thu, 15 Feb 1996 10:08:59 +0100 From: Alan Jackson <mailto:alan_j@SUPVAX.SLS.CO.UK> Subject: Re: Z39.50 and the World Wide Web (fwd) To: Multiple recipients of list WEBCAT-L <mailto:WEBCAT-L@WUVMD.WUSTL.EDU>
Apologies if you received a messed-up version of this posting but the VAX just threw a wobbly..In relation to the stateful cgi model I outlined, Jon Knight asks:
>What happens if the TERMINATE never comes? If the user follows some
>other link or just quits his browser or unplugs his machine, the client
>will never invoke the CGI script that sends the waiting process on the
>server a TERMINATE.
As I indicated in my original posting, on the Web this situation is likely to be the rule rather than the exception. Each time the process is accessed by the user a timer is started (the length of which is controlled by the institution). After a period of inactivity (eg the user has simply gone away), the process closes the Z39.50 connection itself (by sending a TERMINATE) and dies.
>... what
>happens to a PRESENT/DISPLAY/SEARCH request that comes in after the
>process has died?
The CGI attempts to talk to its child process (using the unique state value it has been lovingly looking after) but, lo and behold, fails to find it. What happens next is moot.
>Does the
>user get an error, or does the CGI script transparently do an INIT if the
>process isn't running?
The simple solution is to display an error message with a link to the search application's calling page, or, in the case of a SEARCH only, make an entirely new sub-process and connection automatically.
>What happens to the working set in the latter case?
I'm not sure what set this refers to. If you mean the Z39.50 set stored in memory then it's gone. If you mean server-side state information that the CGI caches on the server for each user (to reduce the amount of information that needs to be transferred back and forth to the client), then this too needs to be deleted so the re-initiated session has lost all context and two different users can't end up sharing the same 'history' cache.
>It was partly due questions like these that made us make our webopac
>stateless on the server side, with the exception of a little hit cache to
>improve performance (an old query that is being continued will still work
>if the cache has been flushed, it just takes a little longer. Most users
>don't notice the difference ...
I view using Z39.50 statelessly to be rather like walking in front of a car with a red flag. If the car is only capable of 5mph and you can walk at 4mph then the loss of utility is minor. However, if the car can do 100mph then your man with the red flag represents a real problem. At the moment, the advantages of using Z39.50 as it was intended - statefully - are not compelling, providing the search engine image is small (ie activates quickly), retrieval is fast and the records are small. But with large, ponderous images and large records (OPAC systems with full MARC records) the scales begin to tip towards stateful transactions. If we now tack in features that may be added to Z39.50 in the future (and who knows what we may have in 18 months?) it makes even more sense to write systems that use the intended features of the protocol, not treat them as something to work around.
BTW, the stateful model I described has no implications for licensing as it retains the concept of simultaneous users that vendors are familiar with. I would also add that the model is not a theoretical concept - the one I've been involved in building is up and running.
Alan Jackson Tailored Information, http://www.datatext.co.uk/ti/