Message-Id: <199602190841.CAA13068@library.wustl.edu> Date: Mon, 19 Feb 1996 08:35:50 +0000 From: Jon Knight <mailto:J.P.Knight@LUT.AC.UK> Subject: Re: Z39.50 and the World Wide Web (fwd) To: Multiple recipients of list WEBCAT-L <mailto:WEBCAT-L@WUVMD.WUSTL.EDU>
On Sun, 18 Feb 1996, Rhyno Art wrote: > > 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 ...
> I'm curious what sort of "caching" you are doing. Is it strictly
> records that have been displayed on the browser or does the
> gateway do something like temporarily store 50 records while
> displaying 10 so that the next couple of steps through the result
> set do not require another connection to the Z39.50 server.
First of all I better point out that our webopac prototype is just that; a _web_ opac. No Z39.50 in sight (our library doesn't have any Z39.50 clients and when we started writing the prototype two years ago, there didn't seem to be much demand in the UK academic community). Our programs talk a SQL directly to the underlying Sybase database that the OPAC is built upon.
The prototype is written in Perl (although the production version that our vendor has just released based on our prototype is written in C) and uses Sybperl to talk to the backend database. We've got a special version of the &sql() function that not only executes some SQL but caches it in a (UNIX) disc file and then returns a limited subset of the retrieved rows. When it is executed again, the new subset is taken from the cached data rather than extracted from the database. This means that the backend database server isn't hit as often and response time is also reduced for this users (the frontend and backend are on two separate machines connected via a private Ethernet).
When the cache gets full, some elements obviously have to be thrown away. If a call is then made to our hacked &sql() function asking for some data that isn't in the cache, the system treats it as though it were the first request for that data and merely retrieves it from the database. This seems to work very well for us. I think our vendor has used something similar in their production version (though I haven't seen the code so I can't be sure - Sybase is pretty damn quick for most search anyway :-) ).
> No doubt we will see lots of variations in using Z39.50 within the
> stateless model but there seems to be great value in improving a
> gateway's ability to make intelligent choices about what may be
> requested without keeping a connection open to the Z39.50 server.
No doubt we will see this sort of thing. However when I hear Z39.50 I can't help but think "WAIS". How many gateways implement relevance feedback for WAIS and moreover, how many people use them compared to simple, easy to understand keyword based search engines such as Alta Vista, Lycos, etc, etc?
> Even if JAVA becomes the preferred method for integrating Z39.50
> and the World Wide Web, there may still be a need for a layer
> between the user's desktop and a Z39.50 target that doesn't tie
> up the resources of the server while performing some of the
> processing, e.g. result set manipulation, that could create a
> large performance bottleneck for JAVA.
The one thing I don't understand about Java Z39.50 clients is that I was under the impression that Java programs could only connect back to the machine from whence they came for security reasons (so that you can't write a Java program that sends an obscene message to mailto:president@whitehouse.gov for example :-) ). Wouldn't this mean that you could obly connect to a single Z39.50 server (the one running on the machine you got the script from)? Or have I misunderstood something?
Tatty bye,
Jim'll
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon "Jim'll" Knight, Researcher, Sysop and General Dogsbody, Dept. Computer Studies, Loughborough University of Technology, Leics., ENGLAND. LE11 3TU. * I've found I now dream in Perl. More worryingly, I enjoy those dreams. *