Re: [search-ws] resultSetIdleTime/resultSetTTL

["Hammond, Tony" <t.hammond@nature.com>]

Title: Re: [search-ws] resultSetIdleTime/resultSetTTL

Hi:

I must admit to still being confused about these parameters. I kind of get the idea, I think. But then I’m not sure. It seems to me that TTL is measured from the original request, and represents a certain fixed period in time where the result set will be alive, whereas IdleTime is a delta from the last request and provides a moving window which can be used to prolong result set lifetime past the original TTL. Is that it? Actually, I really am horribly baffled by all of this.

I think a diagram showing timeline and requests would be very helpful here.

It seems on the face of it a good idea to duplicate the parameters at request and response ends.

I am not sure that I agree with the restrictions on IdleTime. It seems to me that it could legitimately be zero. And certain implementations (ours) would want it to be zero.

(I explained in an earlier mail our methodology. We do not store the result set but the result set query. In fact to do otherwise seems impractical, especially if one is dealing with result sets of 100,000 records, or more. So we return a good faith result set with a smallish TTL. We do not guarantee that the result set will be identical, although we intend it to be so. As long as no content is loaded to the system in the TTL interval then we are good.)

A couple other notes:

    1. Regardless of request parameters wouldn’t we require that the response show both parameters? Values would be server determined modulo client request. So, a response would show TTL and IdleTime. But measured from what?

    2. I disagree that resulSetIdentifier be dropped. You say “if the server does not intend that the result set be referenced”. I think by reference you intended “retrieved”. But it is for very reasons of referencing that one would (and must) include an identifier – even for historical purposes.

One picture might tell us the whole story.

Cheers,

Tony


On 13/4/10 18:37, "Ray Denenberg, Library of Congress" <rden@loc.gov> wrote:

> I notice that we have not resonved the resultSetIdleTime/resultSetTTL issue.  
>  
> Here is my proposal. 
>  
> The problem is we have request parameter resultSetTTL (time to live)  and response element <resultSetIdleTime>  (idle time) and they don't mean the same thing.    I suggest we add  a request parameter idle time and a respnse element time to live, so that we would have complete symmetry, two request parameters: resultSetTTL  and resultSetIdleTime, and two  response elements: <resultSetTTL>  and <resultSetIdleTime>.  Everything optional.  Existing implementations unaffected.  Client proposes a ttl, server responds with actual ttl. Client proposes an idle time, server responds with an actual idle time.  So the current section  would be replaced by:
>  
>   resultSetTTL, and resultSetIdleTime
> In the request the client may supply one or both of the request  parameters resultSetTTL  and resultSetIdleTime.  These are respectively the result set time to live and idle time. Both are values of duration, in seconds. In the time to live parameter, the client is suggesting that the result set need exist no longer than the specified time.  In the idle time parameter, the client request that  the result set remain available and unchanged (both in content and order) until there is a period of inactivity exceeding this idle time.  If both parameters are supplied, the value of resultSetIdleTime should not exceed that of resultSetTTL.
>  
> In the response the server may supply one or both of the response elements <resultSetTTL>  and <resultSetIdleTime>.  Either of these may be supplied or omitted whether or not the corresponding parameter was supplied in the request and the value in the response need not agree with the value in the request if supplied.  If both elements are supplied, the value of <resultSetIdleTime> should not exceed that of <resultSetTTL>.
> <resultSetIdleTime> and <resultSetTTL> are  good-faith estimates by the server of the idle time and time to live. That is, the server projects, but does not guarantee these values.  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.)

********************************************************************************   
DISCLAIMER: This e-mail is confidential and should not be used by anyone who is
not the original intended recipient. If you have received this e-mail in error
please inform the sender and delete it from your mailbox or any other storage
mechanism. Neither Macmillan Publishers Limited nor any of its agents accept
liability for any statements made which are clearly the sender's own and not
expressly made on behalf of Macmillan Publishers Limited or one of its agents.
Please note that neither Macmillan Publishers Limited nor any of its agents
accept any responsibility for viruses that may be contained in this e-mail or
its attachments and it is your responsibility to scan the e-mail and 
attachments (if any). No contracts may be concluded on behalf of Macmillan 
Publishers Limited or its agents by means of e-mail communication. Macmillan 
Publishers Limited Registered in England and Wales with registered number 785998 
Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS   
********************************************************************************