Re: [search-ws] resultSetIdleTime/resultSetTTL

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

Well let me preface by saying I'd get rid of all of this if it was a clean 
slate but it isn't.   We have (in 1.x) the client proposing a TTL and the 
server responding with an idle time, and that makes no sense at all.  But we 
have to retain these for compatibility. (And my idea to add the missing one 
on each side for symmetry seems to me the best way to simplify the picture.)

Next, note that in no case is the server guaranteeing these values, either 
one. They are only projections.  If the server says idle time one hour, it 
is projecting that it will keep it available for an hour, but that may end 
up being three hours, or it may be three minutes. Same for TTL.

So no, there's no mathematics here, you don't include a time of response, 
since these are only estimates.  And most importantly, these are all 
optional. So no, I DON'T suggest that you add them in, I only suggest that 
we add them to the protocol.  You (in your implementation) can ignore them 
altogether.

It's all really just to give the client a bit of a heads up, but nothing 
precise or formal.

Given all that is it really that complicated?

--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: Friday, April 16, 2010 11:48 AM
Subject: Re: [search-ws] resultSetIdleTime/resultSetTTL


> Hi Ray:
>
> Thanks. I got that now. So, you're saying that TTL is max time and that
> IdleTime marks how long the result set stays alive unless another client
> request steps in and then IdleTime gets reset by the server (until expiry 
> of
> TTL).
>
> So, I have another question. In my response I currently have IdleTime. I
> don't have current time of response, do I? Nor do have TTL, although you
> suggest that we should add that in. But then I don't have the original 
> time
> the request was made and from which the TTL is measured.
>
> This is really complex stuff. (And btw, I am still holding out for a 
> diagram
> to clarify.)
>
> Also it looks like even though we are to report IdleTime *and* TTL in the
> response we have no times (request and/or original request) from which to
> measure these offsets. That is, the client has to take care of time
> management.
>
> Who would have thought it was this difficult to query?
>
> Cheers,
>
> Tony
>
>
>
>
>
>
> On 16/4/10 15:35, "Ray Denenberg, Library of Congress" <rden@loc.gov> 
> wrote:
>
>>
>>  From: Hammond, Tony
>>> 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.
>>
>> Tell me if this helps and then we'll go from there.
>>
>> The search response says resultSetTTL is two weeks and resultSetIdleTime 
>> is
>> one hour.
>>
>> This means:
>>
>> If the client references that result set within an hour, then that one 
>> hour
>> timer gets reset for another hour.  If an hour goes by without a 
>> reference,
>> the result set goes away.  In any case, the result set goes away after 
>> two
>> weeks, even if it is constantly referenced.
>>
>> (So no,  idle time does not prolong lifetime beyond TTL. TTL is the max.)
>>
>> --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
>>
>
>
> ********************************************************************************
> 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
> ********************************************************************************
>