Comment 0 for bug 954206

DELETE EVENTS
============================================

PRESENTATION

When it comes to handling the deletion of files (local or remote -FTP/SSH/etc-), Zeitgeist supports the logging of DELETE_EVENTs, but that's about it.

There's no clear distinction between what exists and what doesn't. The addition of the current_uri field made this worse, since if a file X is deleted and at some later point a new file is created with the same name they will be considered the same.

PROPOSAL

I propose two measures that should give us some pretty reasonable handling of deletions:

a) Extend the StorageMonitor extension with a concept of "deleted resource". Insertion of DELETE_EVENTs (for local files, and possible ftp/sftp/etc) will update the value of "storage" where appropriate so the deleted events will be filtered out when querying with StorageState.AVAILABLE.

b) In the engine itself, process DELETE_EVENTs by updating the "current_uri" of relevant subjects. The new URI will take a form like "deleted://%d" where %d is an identifier unique for each deletion (incremental integer, most likely).

RANDOM (UNRELATED) THOUGHTS

 * This just made me think, would it make sense to add a new "resource" table for data shared between subjects (ie. current_uri and storage)?

 * Also, would a current_origin field be useful=