[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Updated Tombstones Draft, Take 2
James M Snell wrote:
> Teo Hui Ming wrote:
> > Hi James,
> > quoted from draft-snell-atompub-tombstones-04:
> >> Linked "trash" resources are orthogonal to the at:deleted-entry
> > element and are intended to provide servers with a way of allowing
> > clients to recover deleted entries.
> > Is there a consensus on recovery mechanism that can (or
> > should it?) be included in tombstones extension?
> Not currently. Recovery is going to mean different things to
> different applications. For some, the entry will still be in
> the database and all that is needed is essentially either a
> move operation or flipping a bit from deleted to not-deleted.
> For others, the data will have been removed from the
> datastore completely and the client needs to completely
> recreate the entry. For now, I imagine that it would be best
> to leave the recovery mechanism undefined and let
> applications get a bit more experience with it before we
> start nailing down any kind of standard or best practice procedure.
I disagree. If there is no recovery mechanism, then what value does standardizing the "trash" link relation have?
As you already pointed out, the trash mechanism is orthonogonal to the tombstone mechanism. It should be specified seperately, along with the recovery mechanism that makes it useful.
> > In this example, does it imply that a trash feed should
> > contain full representation copy of entries, so that the second author
> > can simply retrieve the copy and POST it back to the original
> > collection feed?
> Quite possibly. I've left this intentionally vague.
> Suggestions welcome :-)
It seems to me that WebDAV MOVE would be a better alternative for moving things between a trash collection and a normal collection (both ways). This would let the user choose whether he wants to delete an entry (DELETE) or just move it into the trash (MOVE).