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/
