Steven Lees wrote: > James Holderness wrote: > > [snip] > But there's definitely a balance to be achieved. It would be helpful to take > a few steps back and spend some time discussing the scenarios, not just the > technical details. From this thread, I've seen a few (not mutually exclusive) > ideas described: > > 1) "hard" delete: delete an item and it's gone forever > 2) "soft" delete: you can delete an item but the data and metadata are > preserved so that you can un-delete the item > 3) ability to delete comments from a blog for spam control > 4) ability to delete posts from a blog > 5) full two-way sync between nodes via feeds > 6) ability to verify the source of an entry or tombstone > > And there are probably more that I missed. >
7. one way (master-replica) full and incremental sync. 8. ability to notify aggregators that content must be removed for legal reasons (e.g. dmca... blech) 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. It also seems clear that the representation of deleted items is distinct from the ability to perform a sync, so it would make sense to separate those as well. Having a separate Tombstones spec is making a whole lot of sense at this point. - James
