I don't buy the example, but I have no objection to the time being in seconds anyway. Ralph > -----Original Message----- > From: Mike Taylor [mailto:[log in to unmask]] > Sent: Wednesday, July 10, 2002 7:12 AM > To: [log in to unmask] > Subject: Re: TTL Unit (Was: draft result set model) > > > > 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 >