OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

search-ws message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Hi Ray:

Well I would certainly prefer that it just got dropped.

Having said that we just put out a patch release which fixed inter alia a
problem reported by a user that we were not including 'resultSetIdleTime' in
our responses:

> Iım having trouble with the SRW response. There is a ³resultset² node, but
> there is no ³resultSetIdleTime² node
> (http://www.loc.gov/standards/sru/specs/search-retrieve.html ).
>  
> Itıs important for us to know it.

So, we fixed this by including the 'resultSetIdleTime' but I don't think we
handled the 'resultSetTTL' request parameter very well (i.e. trying to read
that as a 'resultSetIdleTime' request).

Bottom line we could very well live without this parameter but would think
about including a 'resultSetTTL' in the response. Hopefully that would be
good enough for our bug reporter too.

Cheers,

Tony



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

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


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]