Print

Print


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
>