On Thu, 3 Jan 2008, James M Snell wrote:
[snip]
I cannot imagine a case where a feed will have multiple trash feeds but
I cannot rule it out either. For now, it would likely be best to simply
leave that bit undefined until it actually becomes an issue.
I suspect there are lots of potential use cases for multiple
"trash/removed/storage" feeds in the digital library/archives space, so I
think it'd be best to address that issue. (Either prohibit multiple or
make them 'type-able').
There could be many ways tombstones are used. For instance, if a paged
feed as a high rate of deletions, rather than letting tombstones
accumulate ad infinitum, the implementation may decide to only list the
most recent deletions in the first ("current") page. Clients that only
Something like a "time-to-live" mechanism for tombstones could be
warranted, perhaps. OAI-PMH defines that per "feed" (a repository has a
deletion policy), but you could easily do it per tombstone as well. Hmmm
-- come to think of it, maybe tombstone ttl policy *should* be defined at
the feed level.
periodically check the feed may miss a few tombstones now and then but
they're also just as likely to have missed the entry that had been deleted.
- James
cheers
Bill
