>From the use cases I've reviewed here...
> 1) "hard" delete: delete an item and it's gone forever
> 3) ability to delete comments from a blog for spam control
> 4) ability to delete posts from a blog
As far as I'm concerned, there's really no difference between these
cases. Whether it blog entries, bookmarks, documents, etc, if an item
is permanently deleted, we need a way of explicitly indicating that
fact. The main reason we need this is to support a number of
application scenarios including removing entries from local client
caches, letting search indexers know that entries should be removed from
their indexes, and keeping replicas in sync with a master.
> 2) "soft" delete: you can delete an item but the data and metadata are
> preserved so that you can un-delete the item
Soft-delete is a special case. With this, entries are moved to a trash
collection. We need a way of indicating that the entry has been removed
from it's original feed, while at the same time indicating it's new
location in the trash feed, e.g., something along the lines of:
<x:deleted>
<id>tag:example.org,2007:foo</id>
<link rel="trash"
type="application/atom+xml"
href="/trash/foo" />
</x:deleted>
Entries in the trash collection can be undeleted or purged. If they are
undeleted, they go back to the original feed and are removed from the
trash. If they are purged, all of the metadata, save the id and perhaps
a timestamp, will be removed from the database.
> 5) full two-way sync between nodes via feeds
This could change but for now, this is not important to us at the
moment. All of our sync scenarios follow a master-replica pattern where
sync is always one-way.
> 6) ability to verify the source of an entry or tombstone
This will definitely be important.
> 7) one way (master-replica) full and incremental sync.
This is a significant use case for us. We must have a reliable and
performant one-way sync model that can support full and incremental
operation. By incremental I mean we need to have the ability to request
a feed listing only changes that have occurred since the previous sync
operation.
Our internally deployed Atom collections are already working with
hundreds of thousands of entries each.
> 8) ability to notify aggregators that content must be removed for
> legal reasons (e.g. dmca... blech)
I'm not certain it's necessary for us to have the ability to specify why
an entry was deleted so this may fall under the same general category as
items 1, 3 and 4 above.
- James
Steven Lees wrote:
> James Snell wrote:
>
>> A common thread across all these scenarios is the need to explicitly
>> indicate the fact that an entry has been removed from a feed. Given
>> that, it would make sense to have a commonly defined tombstone
>> mechanism.
>
> I agree that this is probably the case, but I'd be more confident about that
> if I were more clear on exactly what scenarios are most important to people.
> Things like ability to un-delete affect the tombstone design. I could see two
> separate designs making sense, although it would be nice if there was a
> super/subset relationship between them.
>
> Steven
>
