Re: [search-ws] resultSetIdleTime/resultSetTTL

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

Hi Ray:

I tend to think that your previous mail was more on target: just keep a TTL
on both sides. (Or if one prefers, call it idleTime both sides.)

To me it looks like there was one concept which spawned two different names
and now we risk trying to come up with two related concepts with their own
separate name. But I'm quite prepared to accept that I may be wrong and this
may be more nuanced than I have imagined.

Principle: SRU 2.0 != SRU 1.*

SRU 2.0 is *not* backwards compatible. We fixed that for good by getting rid
of version and operation (and/or making them optional). That and the
numerous other *major* additions to support media types, facets, result
analysis means that we should not be afraid to recognize that we have
something rather new on our hands and where necessary we should replace
rather than repair.

I think one parameter for result set lifetime determined by the server with
input via a request from the client and reported back to the client is more
than sufficient.

Cheers,

Tony



On 23/4/10 14:33, "Ray Denenberg, Library of Congress" <rden@loc.gov> wrote:

>> The number of seconds for which the client requests that the result  set
>> created should be maintained. The server MAY choose not to fulfil  this
>> request, and may respond with a different number of seconds.
> 
> This is clearly flawed. The server cannot "respond with a different number
> of seconds" because it doesn't have ttl, it only has idle time.  There are
> too many possible interpretations.  Based on all of this discussion and in
> particular Ralphs most recent note I think we should stick with the
> two-parameter symetric approach we've worked out and call it a day.
> 
> --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   
********************************************************************************