Peter Keane wrote: > The trash feed is primarily for recovering a soft-deleted item correct? > The OS analogy is a bit strained since the OS "trash" is the means by > which you get rid of stuff and only secondarily provides a means to > retrieve things. Something like "removed" or "archived" or some such > might be more descriptive. >
Yeah, I'll be working on the descriptive test around that a bit. It's not just for soft-delete. The entry could have been permanently removed from the underlying data store and added to a statically generated trash file, primarily for the purpose of keeping it around so it could be recreated later as a new entry. > This "trash/removed/archived" feed is optional, correct? I.e., it'll be > used by server implementations optimized for soft-deletes (and wouldn't > likely be used for comment spam, for instance)? > Right. The trash feed is primarily intended to be used by the server to provide the client a means of recovering deleted entries. For things like comment spam, the trash feed is not going to be needed. > Also, since deleted-entry has an atom:id I can happily keep thinking of > it as a kind of entry (quacks like a duck... ;-)), so I'll rescind my > previous compliants. :-). quacks like a duck with significantly fewer feathers. > > All-in-all this looks like it covers the cases described in OAI-PMH > (which from my POV is a very good thing). > Good to hear. FWIW, after reading through the links you provided, I had come to the same conclusion. - James > thanks! > peter keane > > On Wed, 2 Jan 2008, James M Snell wrote: > >> >> +1. I was already thinking that some text was needed describing the >> relationship between these. >> >> - James >> >> Mark Nottingham wrote: >>> Hmm. It seems like you need to say something to this; otherwise people >>> may get the feeling they can use them separately. >>> >>> Cheers, >>> >>> >>> On 03/01/2008, at 3:52 PM, James M Snell wrote: >>> >>>> >>>> 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/ >>>>> >>>>> >>> >>> >>> -- >>> Mark Nottingham http://www.mnot.net/ >>> >>> >> >
