[OAI-implementers] Better resumption mechanism - more importa nt than ever!
Wed, 06 Mar 2002 11:33:53 -0800
--On Tuesday, March 5, 2002 3:24 PM -0500 Hussein Suleman <firstname.lastname@example.org> wrote:
> to state the stateless resumption problem a little differently:
> is the OAI protocol idempotent ?
> if a request is submitted twice, will the responses be identical ?
> obviously not, since new records could have been added.
If a request has two time bounds, both in the past, then the protocol
should be idempotent. The protocol would need to outlaw back-dated
changes (put in this record today and date it yesterday).
With only a beginning bound, the protocol is not idempotent.
Requests with "until now" or "until next week" have other problems,
like clock skew. It is better to get the current server time, then
> if we update a record, its datestamp would cause it to move out of
> range of a from/until specification. is this the only case where
> the weaker condition fails ? if so, what if we ditch the until parameter ?
Requiring "until" might be a better path to statelessness. If a
record falls outside the bounds, that isn't a tragedy. It will be
picked up on the next harvest. There is always a window where
the read is before the write. The only question is how big.
As for EDTcat, this protocol needs a set of use cases. Then we can
separate kinds of problems: the protocol doesn't meet its intended
uses, or the intended uses missed an important case.
If anyone needs mood music for working on this, the Lene Lovich
album "Stateless" has been released on CD.
Walter R. Underwood
Senior Staff Engineer
Inktomi Enterprise Search