First, Cheshire3's SRU server (written by Rob Sanderson) implements both
resultSetTTL and resultSetIdleTime.
resultSetTTL as a request parameter seems ambiguously and possibly
overloaded. resultSetTTL primarily ask that the server maintain the
resultSet for at least this long (which it may or may not do), but could
there also be an expectation (on the part of the client) that the server
_will_ expire the resultSet after this time?
Actually given the standard definition of resultSetIdleTime:
"The number of seconds after which the created result set will be
deleted. The result set may also become unavailable before this."
resultSetTTL would be a more accurate name for this response parameter.
A more accurate definition of resultSetIdleTime should read something
more like:
"The number of seconds for which a result set must remain idle (i.e. not
retrieved), before it will be deleted."
In summary, I'd like to see both parameters remain, and resultSetTTL
added as a response parameter in order to express:
"The number of seconds after which the created result set will be
deleted, regardless of any activity in the meantime."
This should not preclude both parameters being returned in a response to
mean:
"resultSetTTL is the number of seconds after which the created result
set will be deleted, however if it is idle for resultSetIdleTime
seconds, it will be deleted earlier."
Just my 2 cents, for what it's worth.
John
On Thu, 2010-03-11 at 15:55 +0000, Mike Taylor wrote:
> On 11 March 2010 14:43, LeVan,Ralph <[log in to unmask]> wrote:
> > I disagree. The client is not saying that they want the result set to actually expire in 30 seconds, they are saying that they would like the idle timeout to be set to 30 seconds. (lol, at least that's the way I've always treated it in my code!)
>
> If that's so, then the request parameter is Just Plain Misnamed, and
> that should be fixed.
>
> But that's not what the specification says.
> http://www.loc.gov/standards/sru/specs/search-retrieve.html
>
>
>
>
> >
> > So, I think the semantics are pretty much the same. Ray seems to want to change the name of the client parameter. Unless servers support both the old and new names, this will inevitably break some clients. Personally, I have no problem, as a server supplier, in being generous in what I accept and strict in what I produce, but I understand that others would prefer not to have the standard larded up with the baggage of our old mistakes.
> >
> > I don't care how this ends up being corrected in the standard: I'll support the old way and the new way as long as I can remember why the old code is in my server.
> >
> > Ralph
> >
> >> -----Original Message-----
> >> From: SRU (Search and Retrieve Via URL) Implementors [mailto:[log in to unmask]]
> >> On Behalf Of Mike Taylor
> >> Sent: Thursday, March 11, 2010 5:33 AM
> >> To: [log in to unmask]
> >> 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 <[log in to unmask]>
> >> 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
> >
> >
--
'. ,'. John Harrison
' ` ' ' University of Liverpool
c h e s h i r e | 3 e: [log in to unmask]
v w: www.cheshire3.org
`-..;.' t: 0151 7954271
.., (c)
|