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.
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)?
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.
All-in-all this looks like it covers the cases described in OAI-PMH (which
from my POV is a very good thing).
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/
