Message-Id: <199602011158.FAA28400@library.wustl.edu> Date: Thu, 1 Feb 1996 11:34:33 +0100 From: Alan Jackson <mailto:alan_j@SUPVAX.SLS.CO.UK> Subject: Re: Search History To: Multiple recipients of list WEBCAT-L <mailto:WEBCAT-L@WUVMD.WUSTL.EDU>
>>One disadvantage I can see of using a web search engine is that there
is, to the best of my knowledge, no way to have a search history capability. With a dedicated Z39.50 client it is easy to keep old search commands (even from session to session) and even sets from previous searches.Does anyone know of any web catalog searching sites that prove me wrong? I suppose a CGI-bin script could be set up that would save old searches within a single session, but that sounds to me like a very large use of resources on the server side, when clients that do the same thing could spread the load around to people's desktops.<<
There are two ways of saving search commands. The first is to pass the commands as hidden form data, at every search adding in the latest command to the next form. The second is to save the commands in a file on the server. Decoding the data is very similar. The first suffers from the overhead of repeated (two-way) transmission of data which will significantly decrease user response time. The second requires disc space on the server but, as it has no response implications, is the better bet.
Text retrieval packages tend to have a history facility in-built, but there is no way to access it under Z39.50 v2 (unless there is a devious bend of the standard that I am not aware of). On the Web you suppose correctly that the implementation route is the CGI script. It isn't, however, a "large use of resources on the server side" (by which I take you to mean disc space) as the data for each stored search command takes relatively few bytes (400 bytes would be considered to be a large search command).
I have no information on the average number of searches a user would undertake in a typical session, but I doubt whether it gets into double figures too often. A user's search history file is, therefore, unlikely to be bigger than 2k-4k bytes. Further, if disc space is limited, the history file can be restricted to the last, say, five commands and it is also likely that there will be a limit on the number of simultaneous users. So at any given time we might consume (temporarily) 20 users * 3k = 60k of disc. Compared to the umpteen megabytes of the catalogue, this server overhead is trivial - and well worth it.
Alan Jackson, Tailored Information Ltd. - http://www.datatext.co.uk/ti/ (currently working on a Web OPAC *with* a search history recall facility)