Re: [search-ws] resultSetIdleTime/resultSetTTL

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

Thanks, Tony.

 "We are still
bemused why there was any need to introduce concept of an idle time over and
above a TTL."

Well I suppose there is still one further alternative to pursue  - which if 
we could do it would be best, I think,  because your diagrams make me 
realize this is even more complex than we realized and I don't think it is 
worth the further effort to engineer all of this to get it worked out.

I think the best approach is to drop idle time at the server.  Simply 
depricate it. So the client suggests a TTL, saying "this result set really 
need live no longer than x minutes" and the server does whatever it wants 
with that information including nothing, but does not respond, neither with 
a corresponding TTL and certainly not with an idle time.

Of course, the problem is that idle time is part of version 1.x.

What do people think about just unilaterally dropping it?

--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
> ********************************************************************************
>


--------------------------------------------------------------------------------


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