Mark Nottingham wrote: > This looks good, except I'm having trouble with the trash feed; is a > client who wishes to implement this spec required to look both for > deleted-entry and link/@rel="trash", polling that if present? If so, it > seems overly cumbersome to implement two mechanisms. >
The client can look for either. Essentially, the deleted-entry element tells you only that the entry was removed from this particular feed. It does not tell you if the entry exists in some other location. The trash feed is orthogonal to deleted-entry and provides a location where things like soft-deleted items can be collected. For instance, suppose we have an Atompub collection managed by multiple authors, Bob and Joe. Bob deletes an entry. Joe discovers that that the entry has been deleted when he sees the deleted-entry element. If Joe wishes to recover the deleted entry, he can go to the trash feed and look for it there. A client could poll the trash feed to discover deleted items if it wishes to do so, but looking for the deleted-entry items would likely be more efficient. - James > BTW, "trash" is culturally specific; how about "garbage"? <1/2 wink> > > Cheers, > > > On 03/01/2008, at 1:15 PM, James M Snell wrote: > >> >> Reviving the Tombstones draft. Consider this a work in progress. >> >> http://www.ietf.org/internet-drafts/draft-snell-atompub-tombstones-03.txt >> >> There are two significant changes: >> >> 1. deleted-entry is now part of the Atom namespace >> 2. a "trash" link relation is registered to point >> to trash feeds. >> >> The trash feed approach and deleted-entry element approaches are >> definitely compatible with one another. They can be used together or >> independently. >> >> - James >> > > > -- > Mark Nottingham http://www.mnot.net/ > >
