[OAI-implementers] Resumption 'from' date.

[Alan Kent]

On Thu, Feb 14, 2002 at 10:38:23AM -0500, Simeon Warner wrote:
> 
> This sounds like a best-practice rather than something that should be
> mandated. Perhaps the suggestion should be:
> 
> "Repositories are encouraged to implement persistent resumptionTokens
> that can be re-used in the event that one a request is not successfully
> completed. One way for repositories to do this is to use the 
> resumptionToken in a way that it encodes the next query in a set of 
> queries that will complete the original List request.
> 
> On failing to complete a request using a resumptionToken, a harvester may 
> re-issue the request using the same resumptionToken. If the repository 
> supports this use then it will give the correct response. Otherwise it 
> will respond with an badResumptionToken error, in which case the 
> harvester must start the complete List request again." 

The only thing to watch out for is that for this to work, there is
also an implicit 'resumptionTokens must never reused' (that is,
they are unique and change per request). Otherwise if a
harvester reuses a token, it wont know if the response is the last
batch again, or the next batch. Is this an acceptable restriction?
I would have thought it would be undesirable. I can imagine a simple
OAI data provider using the resumption token to identify a cached query
that results are being pulled from. There would be no need to change
token. Mind you, just as easily I guess that implementation could put
a count on the end of the token (1, 2, 3) making each token unique
fairly easily. So I am unsure whether the restriction is acceptable
in general or not (people seem strongly in favour of not adding
restrictions, which is fair enough).

Maybe a mix of your proposal plus some information in the Identify response
which indicates that resumptionToken's can be used in this way. In that
case, the proposed text could be simpler - if the server says it supports
unique tokens and for tokens to be reused (unless they time out), then
the harvester can attempt to recover. Otherwise, start again. Then there
does not need to be a new error condition (other than what servers already
implement if unknown or timed out resumptionTOkens are used).

Alan