[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 ********************************************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]