On Dec 18, 2007 12:57 AM, James M Snell <[EMAIL PROTECTED]> wrote:
> FWIW, this is the model currently implemented by the Lotus Connections
> Activities component.
Good.
> The primary reason it works is because Activities
> uses the notion of a soft-delete; where a deleted entry is moved to a
> Trash collection and all of it's metadata is preserved. The entry still
> exists, it's state has just changed. A soft-deleted entry can be
> undeleted and restored to it's original collection or purged. We have
> no way of representing a purged entry because the data is completely
> removed from the database.
Not true, the *only* thing you need is the atom:id, everything else
in the purged entry can be auto-generated.
>
> If a system is using soft-deletes and the notion of a trash collection,
> then I would say that this is a fairly good approach, mainly because the
> atom:entry element are pointing to something that still actually exists.
> However, if the system is doing a hard-delete and is only preserving
> the id of items that have been deleted, it does not make any sense to
> represent those deleted items using the atom:entry element and doing so
> runs the risk of confusing certain clients into thinking that they're
> looking at some piece of content that still actually exists on the server.
Sorry, that's a straw-man, these are completely different feeds living at
different URIs, there's no chance of "confusing certain clients".
Worst case an aggregator is subscribed to both feeds and
it combines all entries with the same atom:id
and over-writes the old entry with the new 'deleted' entries
auto-generated content. Oh wait, that's *exactly* what you'd want
to happen.This just reinforces the idea of altering the entry with
auto-generated content, like changing the title
to "Tombstone Number {num}".
-joe
--
Joe Gregorio http://bitworking.org
