[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [search-ws] resultSetIdleTime/resultSetTTL
Well another possibility, which I should have thought of, would be to change idle time to TTL in the response. This would be equally disruptive and equally simplifying to just eliminating idle time. Actually, I think it would be a more logical approach. --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 10:22 AM 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]