RE: [search-ws] Fw: resultSetTTL and resultSetIdleTime

["LeVan,Ralph" <levan@oclc.org>]

Done.

Ralph

> -----Original Message-----
> From: Ray Denenberg, Library of Congress [mailto:rden@loc.gov]
> Sent: Thursday, March 11, 2010 10:23 AM
> To: OASIS SWS TC
> Subject: [search-ws] Fw: resultSetTTL and resultSetIdleTime
> 
> See Mikes message. I assume everyone here is on the SRU list.   I
don't
> think Mike is correct but I'd prefer someone else argue with him.
> Prefereably Tony, but anyone will do.
> 
> --Ray
> 
> 
> ----- Original Message -----
> From: "Mike Taylor" <mike@INDEXDATA.COM>
> To: <ZNG@LISTSERV.LOC.GOV>
> Sent: Thursday, March 11, 2010 5:32 AM
> Subject: Re: resultSetTTL and resultSetIdleTime
> 
> 
> You can't just rename one of these -- they have different semantics.
> One is total time to live,  the other is how often it needs pinging in
> order to live forever.  If you change one of the names, you need to
> change the semantics, too.
> 
> 
> On 10 March 2010 20:33, Ray Denenberg, Library of Congress
<rden@loc.gov>
> wrote:
> > The OASIS Search Web Services TC solicits feedback from SRU
> implementors
> > on
> > the following issue.
> >
> > SRU defines the request parameter resultSetTTL and response element
> > resultSetIdleTime.
> >
> > These are described as follows:
> >
> > -------------------------------------------------------------
> >
> > The client may request, via parameter resultSetTTL, that the server
> > maintain
> > the result set to be created for a specified period of time (in
seconds).
> > The server may choose not to fulfill this request, and may respond
with a
> > different value, via the response element resultSetIdleTime.
> >
> > The response element <resultSetIdleTime> is a good-faith estimate by
the
> > server of the idle time, in seconds. That is, the server projects
(but
> > does
> > not guarantee) that the result set will remain available and
unchanged
> > (both
> > in content and order) until there is a period of inactivity
exceeding this
> > idle time. The idle time must be a positive integer, and should not
be so
> > small that a client cannot realistically reference the result set
again.
> > If
> > the server does not intend that the result set be referenced, it
should
> > omit
> > the result set identifier in the response.
> >
> > <resultSetIdleTime> is independent (from a protocol point of view)
of
> > resultSetTTL. It may be less-than, equal-to, or greater-than
resultSetTTL,
> > and may be supplied or omitted regardless of whether resultSetTTL is
> > supplied or omitted.
> >
> >
---------------------------------------------------------------------
> >
> >
> >
> > The TC would like if possible to give these both the same name, that
is,
> > either rename the request parameter resultSetIdleTime or rename the
> > response
> > element resultSetTTL. We're not sure if anyone has implemented
either of
> > these, and if not then we could rename one or the other without
breaking
> > any existing implementations. If there are existing implementations
of one
> > but not the other, then we could rename the latter. If there are
existing
> > implementations of both of these, we will drop the idea altogether.
> >
> >
> >
> > So we would like to hear from anyone who has implemented either or
both of
> > resultSetTTL or resultSetIdleTime.
> >
> > --Ray
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>