Date:         Wed, 10 Jul 2002 12:11:59 +0100
Reply-To:     "Z39.50 Next-Generation Initiative" <[log in to unmask]>
Sender:       "Z39.50 Next-Generation Initiative" <[log in to unmask]>
From:         Mike Taylor <[log in to unmask]>
Subject:      Re: TTL Unit (Was: draft result set model)
Comments: To: [log in to unmask]
In-Reply-To:  <[log in to unmask]> (message from Ray Denenberg on Tue, 9
              Jul 2002 09:56:21 -0400)

> Date: Tue, 9 Jul 2002 09:56:21 -0400
> From: Ray Denenberg <[log in to unmask]>
>
> > I can easily imagine a situation in which I might want to have me
> > SRW client say "keep this around for twenty seconds" or similar.
>
> Can you give an example? (20 seconds doesn't seem even long enough
> to make another request.)

I knew you'd ask that :-)

OK, here's my example.  Suppose you provide a Zthes-like service on
your SRW server.  (For those who are not familiar with it, Zthes is a
profile for navigating through hierarchical thesauri in which each
term is represented as a record in a Z39.50 database -- see
zthes.z3950.org)

I'm looking at the display for some term X.  The display includes a
list of narrower terms, which I vaguely recognise but want to see in
more detail.  So I click the "show me scope notes" button which
searches for the records representing those NTs, and gives me a list
of the first ten of them, expanded to include not just the terms
themselves but also their notes.  I might want to do "next ten" a few
times, but I definitely won't want to keep that result set around for
long, since I am, in all probability going to follow one of the links
to see one of the NTs in all its glory (and then continue browsing
through the hierarchy).

The search that gives me the list of NTs with scope notes needs to be
persistent (i.e. have a result set) so I can do "next ten" reliably.
But it's expected lifetime is substantially less than a minute.

 _/|_    _______________________________________________________________
/o ) \/  Mike Taylor   <[log in to unmask]>   www.miketaylor.org.uk
)_v__/\  "Faster hardware is not destined to perform tasks faster,
         but encourages us to use inefficient techniques to build
         larger applications in less time" -- Geoffrey Welsh