OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

search-ws message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 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 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]