@dr.dimitru Exactly! The API should have two methods
trash. It should give two hooks to validate usage of these two methods.
For simplicity I think you should continue using a MongoDB collection to publish what files are available and this collection could be freely updated by the user, to add metadata for instance (I don’t know what would be a reliable way of preventing the user from calling
remove on this collection, or breaking the database by updating library specific fields with
update). If you do not do this, you still need to have a way to list what files are available for garbage collection purposes (for instance uploads that succeeded but that were never linked to anything in the user’s system).
Furthermore I suggest that supported 3rd party storage should have implementation (plugins?) rather than documentation only (if someone is willing to do maintenance). In an application I work on I use file storage for instances deployed on my own hardware because I don’t want to upload sensitive data to the cloud and I want to simplify backup/restore/migration procedures by storing everything in the database. Therefore I use GridFS and I find that having to write your own hooks for such a standard solution feels a bit shaky. I would be more confident using a plugin that occasionally gets updates from the community that are then automatically deployed on the next dependency upgrade. Low-level hooks (
afterTrash) should remain to allow for unsupported storage solutions.