[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [search-ws] SRU 2.0 Draft: Language re resulSetTTL/resultSetIdleTime
If we were to align the names I would want to make the choice of least impact. My guess is that there are more implementations of the response element than there are of the request parameter and if that's the case then it would have less impact to change the name of the request parameter. --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: Monday, March 08, 2010 10:23 AM Subject: Re: [search-ws] SRU 2.0 Draft: Language re resulSetTTL/resultSetIdleTime >I may be being obtuse here but isn't TTL (i.e. 'resultSetTTL') a more usual > network terminology? > > But then having said that we have been asked specifically by one user to > provide a 'resultSetIdleTime' param value to complement the 'resultSetId'. > (Apparently their implementation requires both parameters.) Although here > I > believe the param value is being sought rather than preserving the name of > the parameter. > > Tony > > > On 8/3/10 15:03, "Ray Denenberg, Library of Congress" <rden@loc.gov> > wrote: > >> We need of course to keep in mind that these go all the way back to the >> original spec, 1.0, so we cannot change either name without some cost. >> >> But I would be in favor of changing the request parmeter name from >> resultSetTTL to resultSetIdleTime, if we could determine that nobody has >> implemented the request parameter or that nobody cares (which I don't >> think >> is terribly unlikely). I don't care much for the idea of aliases. >> (Ralph's >> idea) because they always seem to get us in trouble, or they don't really >> reduce any complexity. >> >> So perhaps we could post a message to the SRU list, asking this. >> >> --Ray >> >> ----- Original Message ----- >> From: "Hammond, Tony" <t.hammond@nature.com> >> To: "OASIS SWS TC" <search-ws@lists.oasis-open.org> >> Sent: Monday, March 08, 2010 7:08 AM >> Subject: [search-ws] SRU 2.0 Draft: Language re >> resulSetTTL/resultSetIdleTime >> >> >>> Hi: >>> >>> I just wanted to flag a rather difficult section (for us) in the SRU 2.0 >>> draft. We had problems with this first time around, and are having >>> problems >>> again as we are preparing a patch release. >>> >>> The language could really benefit from some simplification. I'm still a >>> little unclear why the request and the response parameters even have >>> different names. >>> >>> Maybe there's a subtle point being made here - but it's hurting our >>> heads >>> trying to arrive at it. >>> >>> Cheers, >>> >>> Tony >>> >>> == >>> 6.5 resultSetTTL, and resultSetIdleTime >>> >>> The client may request, via parameter resultSetTTL, that the server >>> maintain >>> the result set to be created for a specified period of time (in >>> seconds). >>> The server may choose not to fulfill this request, and may respond with >>> a >>> different value, via the response element resultSetIdleTime. >>> >>> The response element <resultSetIdleTime> is a good-faith estimate by the >>> server of the idle time, in seconds. That is, the server projects (but >>> does >>> not guarantee) that the result set will remain available and unchanged >>> (both >>> in content and order) until there is a period of inactivity exceeding >>> this >>> idle time. The idle time must be a positive integer, and should not be >>> so >>> small that a client cannot realistically reference the result set again. >>> If >>> the server does not intend that the result set be referenced, it should >>> omit >>> the result set identifier in the response. >>> >>> <resultSetIdleTime> is independent (from a protocol point of view) of >>> resultSetTTL. It may be less-than, equal-to, or greater-than >>> resultSetTTL, >>> and may be supplied or omitted regardless of whether resultSetTTL is >>> supplied or omitted. >>> == >>> >>> >>> ***************************************************************************** >>> *** >>> 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 >>> >> >> >> --------------------------------------------------------------------- >> 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]