...
- When the module is disabled, we could offer an e-mail based strategy to process archive requests (as in "Completed Work" above)
- To enable the module, configure one or more backup extractors (possibly in an array in the configuration?)
- When the module is enabled, unarchived files offer an "Archive" option in the UI - when pressed, config is checked for which extractor should be used for archival and request is sent
- If useful, this could potentially offer multiple archive targets if more than one is configured - e.g. S3, NFS, Glacier, etc
05/29 discussion notes
- We have an Archive/Unarchive button alongside Download, and Download is hidden if the file is Status: Archived
- Sends an 'archive' or 'unarchive' parameter to extractor so 1 extractor can handle both modes
- Add a new Archive permission that we can configure like the others - gives us nice control over who can archive things, where
- extractor_info has a category that allows the UI to filter which are shown
- Could potentially implement support for the Process block in extractor info as well - trigger on S3/Mongo/Disk storage, certain MIME types, etc.
- Global and per-space lifetime setting (30 = archive if file is not downloaded for 30 days)
- https://opensource.ncsa.illinois.edu/bitbucket/projects/CATS/repos/clowder/browse/app/services/mongodb/MongoDBSpaceService.scala#449 this might have been the start of implementation, but this function is not used anywhere
Open Questions
- Is this new optional functionality a Play! Framework "module"? Perhaps this is something entirely different?
- Should we support multiple archive options simultaneously (similar to the proposed Multiple Storage Backend feature)?
- Could we easily provide a common pattern for extractor developers to use as a base for such archive/unarchive extractors?
- Would such a pattern require two different extractors? Could we easily parameterize the `process_message` call?
- Should the backup extractors also be listed in the Manual Submission view with the other extractors?
- This could confuse end users, but as long as extractor is SAFE this should be ok - this may take careful design
...