[OAI-implementers] Better resumption mechanism - more importa
nt than ever!
Wed, 6 Mar 2002 21:17:21 -0500 (EST)
On Thu, 7 Mar 2002, Alan Kent wrote:
> On Wed, Mar 06, 2002 at 11:33:53AM -0800, Walter Underwood wrote:
> > 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).
> Is this true? (If so it will change my *possible* implementation ;-)
> I agree that new records being added should never be back dated,
> but what if an old record is updated?
I don't think the protocol is idempotent. If a record is changed, it's
datestamp should be updated too, so a query to past (from->until) may be
quite different. And the old record should not be kept. (Except in special
case like CVS, you will give it another OAI id, that's a different problem
> For example, if a record is inserted in May then updated in July and I
> do a query from Jan to June (ie, including May but not July), then
> should I get back the old May copy of the record? Or because the record
> has been updated (in July), does that mean it is valid for me no longer
> to return the May version of my record and only return the July
> version (when appropriate)?
The objective, as I understand, is to reach a consistent view for
different harvesters, based on frequent fresh harvesting. Let's assume
two harvesters, say H1 and H2. Like your case, we have a record X inserted
in May and updated in July. If H1 starts harvesting in April, it will get
an old version of your record in May, but if H1 is doing a regular fresh
harvesting, it will pickup the changes sometimes in July; and H2 starts
harvesting in Aug, it will get a new version of X and never know what's
happended to X before. By this way H1 and H2 will have the same view of
> If I don't need to return the May version, the the protocol would not
> be idempotent. This was my current understanding from old postings on
> the list. If I must/should return the May version of the record still,
> then I will need to rethink how I implement my harvester (which might
> turn into an aggregator). Currently I keep the most recent record
> version and throw away old versions (by doing updates on the old
> Doing a search service would also be different because I doubt people
> want to do a search and find the old version of the record.
> OAI-implementers mailing list