Re: [search-ws] resultSetIdleTime/resultSetTTL

["Ray Denenberg, Library of Congress" <rden@loc.gov>]

Thank, Tony.  I put this in the new draft I just now posted
http://www.oasis-open.org/committees/download.php/37433/sru-2-0-april-22-2010.doc

But I do see two problems.

One, in B, idle time is greater that ttl. According to the current (draft) 
rules, idle time must be less than or equal to ttl.

Two, in C, I think you meant to say that the result set is dropped at t2? 
Either that or I cannot completely decipher the picture.

--Ray

----- Original Message ----- 
From: "Hammond, Tony" <t.hammond@nature.com>
To: "Ray Denenberg, Library of Congress" <rden@loc.gov>; "OASIS SWS TC" 
<search-ws@lists.oasis-open.org>
Sent: Wednesday, April 21, 2010 5:57 AM
Subject: Re: [search-ws] resultSetIdleTime/resultSetTTL


> Hi Ray:
>
> Attached is a .png of four scenarios for resultSetIdleTime vs 
> resultSetTTL:
>
>    A. Single request: resultSetIdleTime (t1) < resultSetTTL (t2). Result
> set is dropped at t1.
>
>    B. Single request: resultSetIdleTime (t3) >= resultSetTTL (t2). Result
> set is dropped at t2.
>
>    C. Multiple requests: last resultSetIdleTime (t1) < resultSetTTL (t2).
> Result set is dropped at t1.
>
>    D. Multiple requests: last resultSetIdleTime (t3) >= resultSetTTL (t2).
> Result set is dropped at t2.
>
> I have also used 'O' for the original request, and 'X' for the dropping of
> the result set. (I guess this is inspired by UML sequence diagrams 
> although
> does not strictly conform. Should it?)
>
> This reflects our understanding of the resulSetIdleTime vs resultSetTTL
> timers.
>
> I'll wait to hear if we've still somehow botched it up. :) We are still
> bemused why there was any need to introduce concept of an idle time over 
> and
> above a TTL.
>
> If the diagram is any good (as is or with any mods) I can always make any
> changes you might require.
>
> Cheers,
>
> Tony
>
>
>
> On 19/4/10 15:55, "Ray Denenberg, Library of Congress" <rden@loc.gov> 
> wrote:
>
>> From: "Hammond, Tony" <t.hammond@nature.com>
>>
>>> But it *is* still confusing and a diagram would help enormously. Don't
>>> worry
>>> I will volunteer to draw one if you want.
>>
>> Yes, I would welcome a diagram. If you can get it to me by Wednesday I'll
>> get it in the draft for next Monday's call, if not, the following draft.
>>
>>
>>> But this seems to be a case where there is an awful lot of
>>> flexibility for how much real gain.
>>
>> Yes, a classic case of overengineering.  But as we see the choices are:
>> 1. Leave it as is.
>> 2. Remove the existing parameters.
>> 3.Fill in the missing parameters.
>>
>> And I think we all agree that 3 is the best solution.
>>
>> --Ray
>>
>>
>>
>>
>
>
> ********************************************************************************
> 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
> ********************************************************************************
>